JWT Algorithm Confusion
JWT algorithm confusion abuses a token header that names its own algorithm — none, HS256 with an RSA public key — when verifiers trust the header instead of a pinned algorithm.
Definition
A JWT carries its algorithm in the header, which is attacker-controlled input. Vulnerable libraries let the token choose the verification algorithm: the alg none attack strips signatures entirely; the HS256-RS256 confusion uses the server public key as an HMAC secret. The fix is servers pinning allowed algorithms per key type and rejecting mismatched headers.
Context and scope
Historic vulnerability class in JWT libraries. Recurs wherever custom token validation or key rotation code trusts the header field.
Common misconceptions
- Modern libraries fixed it forever — the flaw reappears in hand-rolled verification and key-type-agnostic checks
- Key confusion needs the private key — the RSA public key is enough: attackers sign HMAC with the published public key material
- Whitelisting algorithms in config is optional — pinning is mandatory; an allowlist default with a bypass parameter is still vulnerable
Anti-patterns
- Reading alg from the token header to select the verifier and accepting none as a valid choice
- Verifying RS256 tokens with a library call whose key parameter also accepts HMAC secrets
- Mixing key types in a JWKS cache without validating that the key type matches the token algorithm
Related concepts
Related examples
Authoritative source
https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
What it is
The token declares how it wants to be verified. Trusting that declaration means the attacker picks the weakest path: no signature at all, or HMAC keyed with a public key that was never meant to be secret. Both historically produced accepted forged tokens.
How it works
In the none variant, the third segment is empty and a permissive library skips verification. In key confusion, the verifier treats the RSA public key bytes as an HMAC shared secret and the attacker, who also knows those public bytes, signs validly. Defense: the expected algorithm is a server constant per issuer and key; the header must match exactly, and key type is validated against it.
When to audit
Custom validation code, key rotation services, and any place accept tokens from multiple issuers. Verify the library pins algorithms and that JWKS key types are checked. Integration tests should submit alg-none and cross-family tokens and expect rejection.
Pitfalls
Some libraries expose an algorithms parameter that defaults to permissive. Multi-issuer systems sometimes branch on kid to pick keys, not on alg to pick verifiers — both must align. Legacy integration endpoints are the recurring home of this bug.