Cybersecurity glossary
What is JWT Key Confusion?
Learn what JWT key confusion is, how attackers sign HS* tokens with RSA public keys, why verifiers fail, and how to bind algorithms to key types to stop forgeries.
Definition
JWT key confusion is a verification flaw where cryptographic key material is used with the wrong algorithm family—most classically treating an asymmetric public key as an HMAC secret—so attackers can forge tokens that a confused verifier accepts as valid.
Why key confusion matters
Public verification keys are meant to be widely distributed. That only stays safe if verifiers use them exclusively for the matching asymmetric algorithms. JWT key confusion breaks that contract by feeding the wrong key material into HMAC or another incompatible primitive.
The classic outcome is devastating: attackers download a public JWK, set alg to HS256, sign with the public key bytes as the secret, and a confused API accepts the forgery.
Core failure modes
Public key as HMAC secret
RS/EC public key bytes are passed into HS* verify because the code treats keys as opaque strings.
Dual-alg verifiers
Services accept both asymmetric and HMAC tokens without separating key stores.
Lost key typing
PEM or JWK type metadata is stripped before the crypto call.
Framework misconfiguration
A library is configured with a key and an open algorithm list that permits unsafe pairs.
Classic public-key-as-HMAC path
Fetch the issuer public key
Attackers obtain the PEM/JWK from documentation or a JWKS endpoint.
Build privileged claims
Forge a payload with elevated subject or roles.
Declare an HMAC algorithm
Set header alg to HS256 (or similar) instead of RS256/ES256.
MAC with public key bytes
Compute an HMAC using the publicly known key material as the secret.
Present the token
Send the forged bearer token to the vulnerable verifier.
Confused verify succeeds
If the server HMACs with the same public bytes, the token validates.
Safe key binding expectations
| Key material | Allowed algorithms | Must reject |
|---|---|---|
| RSA public JWK/PEM | RS*/PS* verify only | Any HS* use of key bytes |
| EC public JWK/PEM | Matching ES* verify only | HMAC or unrelated curves |
| Symmetric secret | Configured HS* only | Exposure via JWKS |
| Unknown / untyped bytes | None until typed | Best-effort auto-detect verify |
Preventing JWT key confusion
- Configure a single expected algorithm family per API audience.
- Use typed key APIs (RSA/EC/HMAC objects), not raw undifferentiated strings.
- Never accept HS* on endpoints that only publish asymmetric verification keys.
- Keep HMAC secrets out of JWKS and out of client-reachable config.
- Add exploit regression tests that attempt public-key-as-HMAC forgeries.
- Review gateway JWT plugins for open algorithm lists.
- Prefer asymmetric verification for multi-service architectures.
- Monitor for sudden shifts in presented alg values on auth endpoints.
The practical takeaway
JWT key confusion is what happens when key bytes are decoupled from their cryptographic meaning. Public keys then become forging tools.
Bind algorithms to key types, close HMAC paths on asymmetric deployments, and test the classic public-key-as-secret exploit as a permanent regression case.
Related security terms
JWT Algorithm Confusion
Closely related failures centered on attacker-controlled algorithm selection.
JSON Web Key (JWK)
Key representation that must preserve type metadata during verification.
JSON Web Signature (JWS)
Signed format whose verification must bind alg to key type.
JWT Signature Bypass
Broader category of accepting tokens without proper signature checks.
JSON Web Token (JWT) Attacks
Overview of JWT exploitation techniques including key confusion.
Frequently asked questions
What is JWT key confusion in simple terms?
The server uses the wrong kind of key for the algorithm on the token. A common bug is verifying an HMAC token with an RSA public key treated as a shared secret, which attackers also know.
How is this different from algorithm confusion?
They overlap. Algorithm confusion emphasizes trusting or switching alg unsafely. Key confusion emphasizes applying key bytes with the wrong cryptographic primitive.
Why does the RSA-public-as-HMAC trick work?
Public keys are intentionally public. If a verifier HMAC-signs/verifies using those bytes as a secret, anyone can compute a matching MAC.
Which deployments are most at risk?
Custom verifiers, polyglot services that accept both HS* and RS*, and code that loads keys as raw strings without type enforcement.
Does publishing a JWKS create this risk by itself?
Publishing public keys is normal. Risk appears when verifiers also accept HMAC and feed those public key bytes into HMAC verification.
How do you fix key confusion?
Allowlist one algorithm family, pass typed key objects, and refuse to run HS* verification against asymmetric public keys.
Can EC keys be confused similarly?
Yes whenever verification code can reinterpret public key material as a symmetric secret or otherwise ignore key type constraints.
References
Explore authoritative guidance and frameworks related to jwt key confusion.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.