RS256: RSASSA-PKCS1-v1_5 with SHA-256 in a JWT

The asymmetry is the whole point. The authorization server keeps the private key and every resource server holds only the public one, so a compromised API cannot mint tokens for the rest of the estate. That is why OpenID Connect names RS256 as the default for ID tokens, and why providers publish public keys at a well known endpoint for anyone to fetch.

RFC 7518 requires a key of 2048 bits or larger. The signature is as long as the modulus, so a 2048 bit key produces a 256 byte signature, 342 base64url characters, roughly eight times an HS256 signature. Moving to a 4096 bit key doubles that again and makes signing noticeably slower, while verification stays cheap, which is the trade to weigh when tokens travel on every request.

Algorithm confusion is the attack this algorithm is famous for. The public key is published, so an attacker takes it, rewrites the header from RS256 to HS256, and computes an HMAC over the token using the public key bytes as the secret. A verifier that selects its algorithm from the header and passes in whatever key it has configured will compute the same HMAC and accept the forgery.

The fix is to decide the algorithm before looking at the token. Configure the verifier with the exact algorithms you accept, reject anything else outright, and use a key object typed to RSA so a symmetric operation cannot be performed with it. The decoder follows the token's own header when offering a verification path, which is the right behaviour for an inspection tool and the wrong behaviour for a service.