JWT Algorithm Confusion (alg:none & RS→HS)

Also Known As

TL;DR

Explanation

Two classic JWT attacks exploit algorithm flexibility. The alg:none attack: some libraries accept a token with {'alg':'none'} and no signature, treating it as valid — an attacker can forge any payload. The algorithm confusion attack: an RS256 token (asymmetric — signed with private key, verified with public key) is downgraded to HS256 (symmetric HMAC). If the library reuses the public key as the HMAC secret, an attacker who knows the public key can sign arbitrary tokens. Defences: always specify the expected algorithm explicitly in the verify call; never accept algorithm from the token header; use a dedicated JWT library (firebase/php-jwt, lcobucci/jwt) that enforces algorithm allowlisting; reject tokens with alg:none unconditionally.

Common Misconception

Why It Matters

Common Mistakes

• Using a JWT library that accepts whatever algorithm is specified in the token header without validating against an allowlist.
• Not explicitly specifying the expected algorithm when verifying — letting the token dictate its own verification.
• Mixing HS256 and RS256 — sending an HS256 token to a server expecting RS256 can cause the public key to be used as the HMAC secret.
• Trusting the decoded payload before verifying the signature — some libraries return data even on verification failure.

Code Examples

JWT::decode($token, $key); // accepts whatever alg the token claims

JWT::decode($token, new Key($key, 'RS256')); // algorithm pinned explicitly

References

• ↗ https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
• ↗ https://portswigger.net/web-security/jwt

Tags

Related Terms