JWT & Token Security Pitfalls

A JWT is three base64url segments — header, payload, signature — joined by dots. The cryptography underneath (HMAC or a signature) is sound. Nearly every JWT vulnerability comes instead from one design decision: the token tells the verifier how to verify it. Attacker-controlled input selecting the verification algorithm is a structural flaw, and it produced two of the most instructive bugs in modern applied crypto.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header  {"alg":"HS256","typ":"JWT"}
eyJzdWIiOiIxMjMiLCJyb2xlIjoidXNlciJ9   ← payload {"sub":"123","role":"user"}
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1g    ← signature

alg: none #

The none algorithm exists in the JWS spec for cases where integrity is provided by an outer layer. Libraries implemented it literally: a token with {"alg":"none"} and an empty signature segment was accepted as valid.

{"alg":"none","typ":"JWT"}.{"sub":"123","role":"admin"}.

Strip the signature, change role to admin, set alg to none, send. The 2015 Auth0 disclosure found this across many major libraries at once. It still surfaces in audits a decade later.

Algorithm confusion: RS256 → HS256 #

Subtler and more interesting. A server verifies RS256 tokens with an RSA public key. The attacker changes the header to HS256 and signs the tampered token using that public key as the HMAC secret.

flowchart LR
  A["Attacker gets<br/>RSA public key<br/>(it's public!)"] --> B["Forge payload,<br/>set alg: HS256"]
  B --> C["HMAC-SHA256 the token<br/>using pubkey bytes as secret"]
  C --> D["Server: alg=HS256,<br/>so verify HMAC<br/>with 'the key' = pubkey"]
  D --> E["Signature matches ✓"]

The server's verify call is polymorphic: it dispatches on the token's alg and passes whatever key it has. For RS256 that key is public; for HS256 it becomes a shared secret the attacker also knows. Both sides use the same bytes and the HMAC checks out.

The fix is to stop asking the token. Decide the algorithm server-side and reject anything else:

jwt.decode(token, key, algorithms=["RS256"])   # explicit allow-list, never from the header

An allow-list of exactly one algorithm closes both alg:none and confusion at once. RFC 8725 makes this a normative requirement.

HS256 versus RS256 is a trust-topology choice #

HS256 uses HMAC: every verifier needs the same secret and can therefore mint indistinguishable tokens. It fits one tightly controlled security boundary, but adding a read-only verifier silently gives that service issuer power. RS256 uses an RSA private key to sign and a public key to verify, so many services can validate without gaining authority to mint.

Neither is universally “more secure.” The decisive question is who may issue tokens and whether verifiers cross trust boundaries. In both cases pin the allowed algorithm server-side, bind each key to one algorithm, and validate issuer, audience, token type, and lifetime.

The rest of the checklist #

The problem correct crypto does not solve #

The usual reason to choose JWTs is statelessness — any server can verify without a session store. That property is the drawback: you cannot revoke a stateless token. Logout, a password change, a role downgrade, or a detected compromise cannot invalidate a signed token that is already issued. It stays valid until exp.

Mitigations, all of which reintroduce state:

• Short-lived access tokens (5–15 min) plus a longer-lived, revocable refresh token held server-side. This is the standard architecture and the reason OAuth 2 is shaped the way it is.
• A denylist of revoked JTIs until their expiry — a session store with extra steps, but a small one.
• A token_version claim checked against the user record — one cheap read, and it invalidates every prior token on password change.