JWT algorithm confusion: how RS256 tokens get forged as HS256

How this is calculated

The trick works because a public key isn't secret. It's on a JWKS endpoint or in the docs, so the attacker can get the exact PEM text the server holds. Older verify functions took one key argument and used the header's alg to decide how to use it. With RS256 in the header, they ran an RSA check. With HS256, they treated the same bytes as an HMAC secret, and the attacker knows those bytes. Fixes landed in the major libraries years ago, but variants keep appearing: a JWKS that lists keys without an alg, a gateway that passes a key to code that supports both families, or a custom verifier that switches on the header. The defense has three parts. Pin the algorithm in the verify call. Store the algorithm with each key, which a JWK does with its alg member, and refuse a mismatch. Keep symmetric and asymmetric keys in separate code paths. The JWT Decoder follows the same rule: an HS token is only checked with a shared secret, and if you paste something that looks like a PEM or JWK as the secret, it refuses and explains why.

Verdict

If your service only issues RS256 tokens, its verifier should reject everything else, HS256 included. Write a test that signs an HS256 token with your public key as the secret and confirm the API rejects it. That one test covers the whole attack.