Home / Knowledge hub / JWT algorithm confusion
Knowledge hub
JWT algorithm confusion
Tricking a server into verifying a token with the wrong signing method.
What it means
A JWT header names the algorithm used to sign it. In algorithm confusion, an outsider changes that header so the server verifies the token a different way from the one intended. The classic case: the server expects RS256, which uses a public and private key, and is tricked into HS256, which uses a shared secret.
If the library then uses the server's public key as the HMAC secret, anyone who knows that public key can sign a valid token. Public keys are meant to be public, so the forger has everything they need.
Why it matters
A forged token can say anything: another user's id, an admin role, a longer expiry. The server accepts it as genuine because the signature checks out, and the whole authorisation model sits on top of that trust. This is a route to privilege escalation with no password at all.
It is an old bug that still turns up in custom code and older libraries. A related case is the none algorithm, where the header declares that no signature is needed.
How it shows up
You meet it in APIs and sign-in services that verify JWTs with a library, especially where the key is looked up from the token header or one function handles several algorithms. The vulnerable pattern is letting the token decide how it is verified.
The fix is simple. Tell the library which algorithm or algorithms to accept, and refuse everything else. Do not accept none. Keep keys typed, so a public key cannot be passed as a secret. RFC 8725 sets out this guidance. Test by changing the header on a captured token.
Questions people ask
JWT algorithm confusion, answered
What is the difference between HS256 and RS256?
HS256 uses one shared secret to sign and verify. RS256 signs with a private key and verifies with a public key.
The confusion attack exploits a server that will verify either way.
Is this the same as the JWT none algorithm bug?
Related but different. The none bug asks the server to skip the signature. Algorithm confusion asks it to use a different algorithm.
Both come from trusting the header, and both are fixed by fixing the allowed algorithms.
Are modern libraries safe?
Most current libraries require you to specify the expected algorithm, which prevents it. Older versions and custom code may not.
Update, and read how your library handles the algorithm setting.
Does using only HTTPS stop this?
No. HTTPS protects the token in transit. This attack happens when the attacker builds a new token and sends it to you.
The server's verification step is the only defence.
How would a pentest find it?
By taking a valid token, changing the algorithm in the header, re-signing with the public key as the secret, and sending it.
If the API accepts it, the report shows the forged token and the response.
Sources
Where this comes from
Related
Terms that sit next to this one
JWT
A signed token a client carries to prove who is signed in.
JWT none algorithm
A token that claims to need no signature, accepted by a careless library.
Digital signature
A value that proves who produced data and that it has not changed since.
Public key cryptography
Encryption with a pair of keys: one shared openly, one kept private.
Privilege escalation
Gaining rights you were never given, sideways or upwards.
Who decides how the token is checked?
Forged and tampered tokens, algorithm swaps and tokens that grant another account's access are within what we test, and a finding shows the token and the response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.