JWT algorithm confusion attacks expose authentication bypass risk

At a glance

What this is: This is a technical breakdown of JWT algorithm confusion attacks and the key finding is that token-supplied algorithm metadata can let attackers bypass signature verification.

Why it matters: It matters because JWTs sit inside human SSO flows, NHI service authentication, and API trust chains, so a single verification mistake can create broad authentication bypass across identity programmes.

By the numbers:

• The Node.js jsonwebtoken library was vulnerable prior to version 4.2.2, making the RS256 to HS256 attack trivial.
• The article notes that algorithm confusion vulnerabilities have been documented since 2015.

👉 Read WorkOS's breakdown of JWT algorithm confusion attacks and fixes

Context

JWT algorithm confusion is a token verification failure where the verifier trusts the token's own algorithm field instead of enforcing the algorithm it expects. That sounds like a small implementation detail, but it changes the trust boundary for authentication across API gateways, SSO integrations, and non-human identity workflows.

For IAM teams, the issue is not JWTs themselves but verifier discipline. When a service accepts attacker-controlled metadata to choose the verification path, the system can be made to accept forged identities, which undermines both human access control and machine-to-machine trust.

For additional context on how identity assurance collapses when credentials or token handling is weak, see the Ultimate Guide to NHIs and the 52 NHI Breaches Analysis. Those resources show why token handling errors often become organisation-wide identity failures rather than isolated code defects.

Key questions

Q: How should security teams prevent JWT algorithm confusion in verification code?

A: Security teams should hardcode the accepted algorithm in the verifier, reject any token that claims a different one, and ensure the key type matches the algorithm family. The safest pattern is simple: the application chooses RS256, ES256, or HS256 up front, and the token cannot override that policy at runtime.

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: What do security teams get wrong about JWT header fields like jku and x5u?

A: Teams often treat them as harmless hints, but they can become a remote trust injection path if the verifier fetches keys from attacker-controlled URLs. Unless those fields are ignored or tightly allowlisted, the token can redirect the trust decision to keys the attacker controls.

Q: Which controls matter most when validating JWTs in SSO and API systems?

A: The most important controls are explicit algorithm pinning, strict header allowlisting, trusted key resolution, and version management for JWT libraries. Those controls stop both algorithm confusion and key redirection, which are the two main ways forged tokens become believable identities.

Technical breakdown

How RS256 to HS256 confusion bypasses JWT verification

In normal RS256 verification, the server uses an RSA public key to check a signature created with the private key. The vulnerability appears when the verifier reads the header's alg value and uses it to choose between asymmetric and symmetric verification paths. If the same key variable is passed into both paths, an attacker can set alg to HS256 and sign with the public key as the HMAC secret. Because HMAC accepts any byte string as a key, the server and attacker compute the same signature and the forged token validates.

Practical implication: pin the accepted algorithm in code and never let the token decide the verification branch.

Why alg none and embedded key URLs are separate failure modes

The alg none issue removes signature verification entirely when a library trusts the token header enough to skip checks. Embedded key parameters such as jku and x5u create a different path: the verifier fetches a signing key from a URL controlled by the attacker unless the implementation enforces a strict allowlist. Both cases are header trust problems, but they fail differently. One turns verification off, the other redirects verification to attacker-owned trust material.

Practical implication: reject unexpected header fields and ignore remote key references unless they are explicitly allowlisted.

Why cryptographic agility becomes a security liability

Cryptographic agility is the idea that a protocol can support multiple algorithms over time. That flexibility is useful for migration, but it becomes dangerous when the incoming message influences which algorithm is considered acceptable. The verifier should own the policy, not the token. A system that treats RS256, HS256, PS256, and other options as interchangeable creates downgrade and confusion paths that the application may never intended to support.

Practical implication: treat algorithm selection as a policy decision, not a token attribute.

Threat narrative

Attacker objective: The attacker wants to mint valid tokens for arbitrary identities or privilege levels without obtaining the real signing secret.

1. entry: An attacker supplies a forged JWT header that advertises a different verification algorithm or a remote key reference.
2. credential_harvested: The verifier accepts the token's alg, jku, x5u, or kid fields and uses attacker-influenced material to validate the signature path.
3. escalation: The attacker signs a token with the RSA public key as an HMAC secret or forces verification against attacker-hosted key material.
4. impact: The service accepts a validly signed token for an identity or privilege set the attacker chose, bypassing authentication and authorisation.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Header-driven verification is an identity trust failure, not just a cryptography bug. The problem begins when a verifier lets token metadata decide the signature path. That breaks the core IAM assumption that the application, not the claimant, controls proof validation. In NHI terms, the token becomes both the identity assertion and the policy input, which collapses the separation between presentation and verification. Practitioners should treat algorithm trust as part of authentication governance, not as an implementation detail.

Algorithm confusion is a named example of verification-path drift. The control gap is not simply outdated code. It is the drift between the expected verification policy and the path actually executed at runtime. Once that drift exists, RS256, HS256, none, and remote key references all become variants of the same governance flaw. The practical lesson is that a verifier without explicit algorithm policy is already outside safe identity assurance boundaries.

Cryptographic agility was designed for controlled migration, not attacker-selected verification. That assumption fails when the token can nominate the algorithm and the key source because the system no longer owns the trust decision. The implication is that identity programmes need to model token verification as policy enforcement, not algorithm negotiation. That shift matters for both human SSO and NHI API authentication.

Embedded key references expose a broader governance blind spot around external trust material. jku, x5u, and similar fields create an implicit supply chain for trust, and most identity programmes do not govern that chain with the same discipline they apply to signing keys at rest. The result is not just a JWT flaw but a recurring pattern in machine identity controls: a trusted object is allowed to redirect trust itself. Practitioners should see this as a key management boundary failure.

JWT libraries can be safe by default, but only when policy is explicit. The historical record across jsonwebtoken, PyJWT, and related libraries shows that defaults matter more than theory. If the calling application does not state acceptable algorithms, the library may do exactly what the attacker wants. Security teams should therefore review verification wrappers, library versions, and any code path that accepts token headers as input to trust decisions.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• Treat the OWASP NHI Top 10 as the next control lens when token, key, and tool trust all intersect in one runtime.

What this signals

Verification-path drift: JWT confusion is a reminder that identity systems fail when the claimant influences the verifier's policy. That pattern now shows up across tokens, service credentials, and agent connectors, which is why token handling needs the same governance attention as key rotation and offboarding.

In parallel, the growth in exposed secrets shows how quickly trust material leaks into places control owners did not intend. With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, per the State of Secrets Sprawl 2026, identity teams should expect more verification paths to inherit untrusted inputs.

For teams building secure token and workload trust models, the OWASP NHI Top 10 is the right companion resource because the same design mistake appears whenever metadata, keys, or tools are allowed to shape trust dynamically.

For practitioners

• Pin the accepted JWT algorithm in code Configure each verifier to accept only the one algorithm it is supposed to process, and reject tokens that present any other value in the alg header. Do not mix symmetric and asymmetric algorithms for the same key path.
• Reject token-supplied key locations Ignore jku, x5u, and jwk unless your application validates them against a strict allowlist and a locally controlled trust boundary. Resolve signing keys from your own configuration or trusted JWKS endpoint only.
• Enforce key type and algorithm agreement Check that symmetric algorithms use raw secret material and asymmetric algorithms use the correct public key object before verification begins. If your library does not enforce that match, add the guard in the caller.
• Audit dependency versions and wrapper code Inventory every JWT library and abstraction in the stack, then verify that defaults require explicit algorithm selection. Older releases and convenience wrappers are where algorithm confusion usually reappears.

Key takeaways

• JWT algorithm confusion is an authentication bypass pattern caused by trusting token metadata instead of enforcing verifier policy.
• The practical risk is broad because the same flaw can affect SSO, APIs, and non-human identity token flows wherever headers drive trust decisions.
• Pinned algorithms, trusted key resolution, and strict header validation are the controls that stop forged tokens from becoming accepted identities.

Key terms

• Algorithm Confusion: A JWT verification flaw where the application trusts the token's algorithm header to choose how a signature is checked. That breaks the verifier's role as the authority on trust policy and can let an attacker force a weaker or attacker-controlled validation path.
• Header Trust Boundary: The point at which token metadata stops being descriptive and starts affecting security decisions. In JWT systems, fields like alg, kid, jku, and x5u must be treated as untrusted input unless the verifier explicitly constrains their use.
• Cryptographic Agility: The ability of a protocol to support more than one algorithm so systems can migrate over time. In practice, agility is only safe when the application fixes the acceptable algorithm set and never lets the incoming token negotiate its own verification rules.
• Key Redirection: A failure mode where a token points the verifier at a key source the attacker controls, often through jku or x5u fields. The issue is not only where the key comes from, but whether the application has any governance over that trust source at all.

Deepen your knowledge

JWT verification hardening is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is standardising token validation across service accounts and API flows, it is worth exploring.

This post draws on content published by WorkOS: JWT algorithm confusion attacks: how they work and how to prevent them. Read the original.