JWT authentication best practices and token validation risks

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: JWT authentication best practices break down when misconfigurations in signing, validation, storage, and revocation weaken token trust.

Why it matters: IAM teams need to treat JWTs as narrowly scoped, verifiable credentials because validation gaps turn otherwise standard authentication into a quiet privilege and session risk.

Context

JWTs are signed, compact claims containers, not encrypted identity objects. That distinction matters because the payload is readable and the signature only proves authenticity, so the security model depends on strict verification rather than assumption.

For IAM and application teams, the risk is not the format itself but the validation boundary around it. A token can be syntactically valid and still be the wrong issuer, audience, algorithm, purpose, or lifetime for the service that receives it.

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 short-lived JWTs reduce authentication risk?

A: Short-lived access tokens reduce the window in which a stolen or misused token remains valid. JWTs are stateless, so revocation is harder than with server-side sessions, and short expiration is the simplest way to limit exposure. It does not eliminate theft risk, but it sharply narrows the time an attacker can use a token.

Q: What are the signs that a JWT validation flow is too permissive?

A: Common warning signs include accepting multiple token types at the same endpoint, skipping audience checks, trusting jku or x5u without allowlisting, and treating decrypted data as automatically authenticated. Another red flag is when the library accepts whatever algorithm the token advertises instead of a fixed allowlist. Those gaps usually show up as unexpected token acceptance across services.

Q: How should security teams store JWTs in browser applications?

A: Prefer storage patterns that reduce script readability and replay risk. HttpOnly cookies with Secure and SameSite flags are usually safer than local storage or session storage when the application can support server-side session handling or a backend-for-frontend design. The best choice depends on XSS exposure, CSRF handling, and whether the token must be readable by client-side code.

Technical breakdown

Algorithm selection and signature verification

JWT verification begins with the signing algorithm, and that choice shapes the trust model. Symmetric algorithms such as HS256 use one shared secret for issuing and verifying, which is acceptable only when the same service owns both functions. Asymmetric algorithms such as RS256, ES256, and EdDSA separate issuance from verification, which is safer in distributed systems because verifiers cannot mint tokens. The dangerous patterns are accepting alg none, trusting the header to select the algorithm, or allowing algorithm confusion where an RS256 token is reinterpreted as HS256 using a public key as the HMAC secret.

Practical implication: Pin the expected algorithm explicitly and reject any token that relies on header-driven algorithm selection.

Claim validation, audience control, and token type separation

A valid signature does not mean the token is valid for your application. The verifier still has to check exp, nbf, iss, aud, and sub, and it must tolerate only small clock skew. These claims prevent stale, mis-issued, or wrong-target tokens from being accepted. Cross-JWT confusion becomes a risk when access tokens, ID tokens, reset tokens, and event tokens share claims and are accepted interchangeably. Explicit typing, mutually exclusive validation rules, and different signing keys per token purpose close that gap.

Practical implication: Validate issuer, audience, expiry, and token purpose together instead of treating signature verification as the finish line.

Header trust, storage, and revocation mechanics

JWT headers can be abused when implementations fetch keys from attacker-controlled jku or x5u values, or when kid is treated as a trusted database lookup. That turns token parsing into an SSRF or injection path. Storage also matters: httpOnly Secure SameSite cookies reduce browser-side theft, while localStorage and sessionStorage are exposed to script access. Revocation remains hard because JWTs are stateless, so short expirations, rotated refresh tokens, denylists, or versioned claims are the practical control patterns that reduce exposure windows.

Practical implication: Treat header fields as untrusted input, keep token storage narrow, and use short-lived access tokens with revocation-aware refresh handling.

Threat narrative

Attacker objective: The attacker aims to turn a forged, stolen, or misvalidated JWT into unauthorized authenticated access.

1. Entry occurs when a verifier accepts a JWT that was signed with the wrong algorithm, the wrong key handling logic, or an attacker-controlled header path.
2. Credential abuse follows when the token is reused outside its intended issuer, audience, or token type, or when a stolen token remains valid for too long.
3. Impact is authenticated access that should have been rejected, including API access, session impersonation, or cross-purpose token substitution.

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.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

JWT validation is an authentication governance problem, not just a library configuration problem: the token format is only as strong as the service's verification contract. When teams treat signed tokens as self-validating, they blur the boundary between authenticity and authorization and create a quiet failure mode that looks like legitimate login traffic. Practitioners should treat JWT acceptance rules as policy, not parsing convenience.

Algorithm confusion is a trust-boundary failure in disguise: the critical mistake is not choosing the wrong cipher, but allowing the token header to choose the verification path. That assumption was designed for convenience, not adversarial input, and it breaks the moment the verifier becomes obedient to attacker-supplied metadata. The implication is that validation logic must be fixed at the service boundary, not inferred from the token.

JWT revocation exposes the difference between session control and bearer control: once a token exists, it remains usable until expiry unless the system introduces explicit state. That creates a short-lived credential model, not a revocable session by default, and governance fails when teams confuse the two. The practitioner lesson is that access architecture must account for token lifetime as a control surface.

Cross-JWT confusion is a purpose-separation problem: access tokens, ID tokens, reset tokens, and security event tokens are not interchangeable even when they share issuer and subject claims. Validation rules that do not distinguish token purpose collapse multiple trust domains into one. Teams should treat token type as part of access policy design, not as an optional metadata field.

Header-driven key discovery creates an untrusted control plane inside authentication: jku, x5u, and kid can turn verification into a network fetch or backend lookup that the attacker influences. That is a governance anti-pattern because the verifier is no longer only checking trust, it is also following instructions from the object being checked. The result is a larger attack surface than most IAM programmes assume.

What this signals

JWT validation should be treated as part of identity control design, not as a postscript to application development: the same token can be authentic, portable, and still unusable for the wrong service if issuer, audience, and token purpose are handled correctly. That means IAM teams need validation rules that are explicit enough to survive distributed architectures and third-party verification.

Bearer token governance is moving closer to session governance: the more an organisation relies on JWTs for access, the more important expiry, rotation, and revocation become as operational controls. The practical boundary is no longer whether the token is signed, but whether the programme can contain misuse after issuance.

For practitioners

• Pin algorithm and token-purpose validation Configure JWT libraries to accept only expected algorithms, token types, issuer values, and audience values for each endpoint. Reject any token that relies on header-selected verification logic or mismatched typ values.
• Treat JWT headers as untrusted input Block or strictly allowlist jku and x5u locations, sanitize kid before any lookup, and refuse network fetching from private or loopback destinations.
• Use short-lived access tokens with rotated refresh tokens Keep access-token lifetimes short, store refresh tokens server-side, and invalidate the refresh token chain when reuse is detected or when user state changes.
• Separate storage choices by client type Use httpOnly, Secure, SameSite cookies for browser sessions, and use native secure storage for mobile clients rather than localStorage or sessionStorage.
• Audit revocation paths and key rotation Verify that expired or revoked credentials cannot still authenticate through cached keys, stale denylist gaps, or missing auth_version checks.

Key takeaways

• JWTs are only safe when services validate more than the signature, because a valid token can still be wrong for the issuer, audience, or purpose.
• The biggest implementation risks come from algorithm confusion, hostile header handling, weak storage choices, and assuming stateless tokens are easily revocable.
• Short-lived access tokens, explicit validation rules, and strict key handling are the controls that keep JWT authentication from becoming silent trust expansion.

Key terms

• Json Web Token: A JSON Web Token is a compact, signed token that carries claims between systems so they can verify identity or authorization without consulting a central session store. In practice, its safety depends on strict validation of the signature, issuer, audience, expiry, and algorithm before any trust decision is made.
• Algorithm Confusion: Algorithm confusion is a verification failure where a service accepts a token under the wrong signing algorithm or uses token-supplied metadata to decide how to verify it. The result is forgery or unauthorised acceptance. It is a classic example of trusting attacker-controlled header data in an identity flow.
• Refresh token rotation: Refresh token rotation replaces a reusable refresh token with a new one each time it is used. This limits the value of token theft because a stolen token becomes useless after the legitimate exchange, assuming the implementation handles revocation and concurrency correctly.
• Cross-JWT Confusion: Cross-JWT confusion occurs when one kind of JWT is accepted as another, such as an access token being treated like an ID token or a password reset token. The fix is not just audience checking, but also explicit token typing and purpose-specific validation rules.

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.