JWT algorithm confusion attacks expose authentication bypass risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: JWT algorithm confusion attacks let forged tokens pass verification when the server trusts the token header to choose the verification path.

Why it matters: IAM and application teams need to treat JWT verification as a policy decision, not a token-driven branch, because a single algorithm mismatch can become full authentication bypass.

Context

JWT algorithm confusion is a verification flaw in which the token itself influences how its signature is checked. In practice, that means the application can be tricked into accepting a forged JWT when it trusts the header's algorithm or key reference fields instead of enforcing its own verification policy.

For identity and access management programmes, the issue sits at the boundary between authentication logic and token trust. A JWT is supposed to carry claims, not control the verifier's algorithm choice, and once that boundary breaks, downstream authorisation inherits a false identity assertion.

Key questions

Q: What breaks when JWT validation relies on the token header to choose the algorithm?

A: The verifier can be tricked into accepting a forged token because the attacker controls the header that selects the verification path. That opens the door to algorithm confusion, especially when an asymmetric token is reinterpreted as a symmetric one. Services should pin the expected algorithm in code and ignore attacker-supplied selection logic.

Q: Why do JWT algorithm confusion attacks bypass normal authentication controls?

A: They work because the verifier trusts attacker-controlled header metadata to select the signature check. Once the application lets the token choose the algorithm, the attacker can force a symmetric verification path or disable verification entirely, which turns a signing problem into a full identity bypass.

Q: How do security teams know whether their JWT implementation is actually using a safe signing key?

A: A safe JWT implementation uses a dedicated, high-entropy signing key that is independent of any user password or account attribute. Teams should verify the key is stored separately, never derived deterministically from credentials, and regularly rotated through controlled secret management. If the key changes when a password changes, the design is too tightly coupled to identity.

Q: Should teams use jku or x5u in JWT headers at all?

A: Only if the verifier resolves keys from a tightly controlled allowlist and never from arbitrary token input. In most environments, the safer choice is to ignore those fields and use locally configured or centrally managed key sets instead of letting the token point to its own trust anchor.

Technical breakdown

Why RS256 to HS256 confusion works

In a normal RS256 flow, the issuer signs with an RSA private key and verifiers check with the public key. The attack succeeds when the verifier reads the token's alg value and switches into HMAC mode, because HMAC accepts any byte string as a key. If the same RSA public key is reused as the HMAC secret, the attacker can compute a matching signature with publicly available material. The flaw is not in RSA or HMAC alone, but in letting untrusted token metadata choose the verification primitive.

Practical implication: verification code must pin the expected algorithm before calling the library, and key type must match algorithm type.

Why none and header-driven key retrieval expand the attack surface

The none algorithm removes signature checking entirely if a server honours it, turning JWT validation into claim parsing with no cryptographic proof. jku and x5u create a different problem by letting the token point the verifier at a key set or certificate URL. If those locations are accepted from the token without a strict allowlist, the attacker can supply their own signing material and make the server validate the forged token against attacker-controlled keys. In both cases, the message is trying to steer the trust decision.

Practical implication: ignore token-supplied key locations unless they are explicitly allowlisted and reject any unexpected JWT header parameters.

How library defaults create repeatable implementation failures

Algorithm confusion keeps recurring because JWT libraries often make the unsafe path easy: decode or verify without an explicit algorithm list, and the library may follow the token header. That design turns a verification API into a policy leak. Mature implementations now force explicit acceptable algorithms or reject mixed symmetric and asymmetric sets for the same key, but older versions and custom wrappers still expose the same failure mode. The technical lesson is that cryptographic agility is only safe when the application, not the token, decides which algorithm is admissible.

Practical implication: audit JWT libraries for default algorithm trust, update old dependencies, and enforce an allowlist containing only the intended algorithm.

Threat narrative

Attacker objective: The attacker wants to create a token that the application accepts as a legitimate identity assertion without possessing the issuer's signing secret or private key.

1. Entry occurs when an attacker presents a crafted JWT whose header claims an acceptable algorithm or a malicious key URL.
2. Credential access is achieved indirectly because the verifier treats token metadata as authority and uses the wrong verification path.
3. Escalation follows when the forged token is accepted as a valid identity assertion with attacker-chosen claims and privileges.
4. Impact is authentication bypass, which can expose downstream applications, APIs, and user sessions to unauthorised access.

Breaches seen in the wild

• Microsoft Storm-0558 key breach 2023: China-based Storm-0558 used a stolen, never-retired Microsoft signing key to forge tokens and read email at 22 organisations in 2023.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Algorithm confusion is a verifier integrity failure, not a token format problem. JWTs are designed to carry claims, but the verifier must own the trust policy. When the algorithm field becomes a control input, the application is no longer validating identity, it is executing attacker-supplied verification logic. The practitioner conclusion is that token parsing and trust selection must be separated completely.

Cryptographic agility becomes a liability the moment the message selects the primitive. RS256, HS256, PS256, and none are not interchangeable choices when one side of the trust relationship is untrusted. The same pattern appears in JWT libraries, custom authentication middleware, and home-grown token wrappers. Practitioners should treat algorithm flexibility as a design risk unless the acceptable algorithm is fixed out of band.

Embedded key references create an identity trust boundary collapse. jku and x5u are convenient only if the verifier already controls where keys can be resolved from. If the token can influence key retrieval, the application has ceded part of its trust anchor to the message it is trying to verify. The implication is straightforward: key discovery must remain inside the verifier's control plane, never inside the token.

JWT verification is a policy enforcement problem that belongs in IAM governance. Authentication teams often assume library defaults are safe enough, but algorithm confusion shows that small API decisions can invalidate the whole identity chain. This is where IAM, application security, and secure SDLC practices converge. Practitioners need explicit ownership of token verification policy, dependency hygiene, and configuration review.

What this signals

Header-driven verification is the real failure mode. The dangerous assumption is that a JWT can tell the verifier how to be verified. That assumption breaks across both library defaults and custom middleware, so the control point has to move from token parsing to explicit policy enforcement.

JWT trust boundaries must stay on the verifier side of the wire. When the application accepts key URLs, algorithm hints, or mixed algorithm sets from the message itself, it creates an authentication boundary that the attacker can influence. That is a governance problem as much as a coding problem.

For practitioners

• Pin the accepted JWT algorithm Specify the exact algorithm list in every verification call and reject any token that presents a different value, even if the signature otherwise verifies.
• Enforce key type agreement Require symmetric keys for HMAC and asymmetric public keys for RSA or ECDSA, and fail closed when the key class does not match the algorithm.
• Ignore token-supplied key locations Disable jku, x5u, and embedded key lookup unless a trusted allowlist exists, and resolve keys only from configuration you control.
• Audit JWT libraries and wrappers Review dependency versions and any local helper code for defaults that infer algorithms from the header or accept mixed algorithm sets.

Key takeaways

• JWT algorithm confusion lets an attacker forge a token by controlling how the verifier interprets the header.
• The issue is not cryptographic weakness in RSA or HMAC, but trust placed in token-supplied metadata.
• Explicit algorithm pinning and strict key-source controls are the controls that prevent authentication bypass.

Key terms

• JWT Algorithm Confusion: A verification flaw where the application lets a JWT header decide which cryptographic algorithm to use. The attacker can exploit that trust to make the server validate a forged token with the wrong primitive or with attacker-controlled key material.
• Algorithm Pinning: The practice of hardcoding the single acceptable signing algorithm in verification logic. For JWTs, this prevents the token from steering the verifier into a different cryptographic path and removes a common source of authentication bypass.
• Header-Driven Trust: A failure mode in which a token header or similar untrusted field influences a security decision. In JWT systems, this often means the message can alter algorithm choice, key lookup, or other parts of the verification path that should remain under application control.
• JWKS: A JWKS, or JSON Web Key Set, is a machine-readable publishing format for public keys used by clients to verify signatures or encrypt tokens. It lets consumers fetch current key material automatically instead of relying on manual distribution, which is critical when keys rotate on a schedule.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.