JWT authentication best practices and token validation risks

At a glance

What this is: This guide explains how JWTs work in production and where common implementation mistakes undermine authentication, especially around signing, validation, storage, and revocation.

Why it matters: It matters because JWT handling sits at the boundary of human IAM, service-to-service trust, and token-based access control, so small validation errors can widen the attack surface across programmes.

👉 Read WorkOS's guide to secure JWT authentication and token validation

Context

JWTs are a common authentication mechanism, but they only work safely when the verifier enforces the expected algorithm, issuer, audience, token type, and lifetime. The security problem is not JWTs themselves, but the way teams assume the token will protect them without strict validation.

For IAM and security architects, the practical issue is that JWTs often sit inside broader identity flows for users, APIs, and service integrations. That means one weak verification path can create confusion across access tokens, refresh tokens, and shared signing keys, especially where multiple services consume the same identity layer.

Key questions

Q: How should security teams validate JWTs in production applications?

A: Validate JWTs with explicit checks for algorithm, issuer, audience, expiration, and token type. Do not trust the token header to choose verification behaviour. A secure implementation treats the JWT as untrusted input until the signature and claims both match the expected service, and it rejects tokens that are valid in general but wrong for that endpoint.

Q: Why do JWTs complicate revocation compared with server sessions?

A: JWTs are stateless, so the server usually does not keep a live record of each token after issuance. That makes immediate revocation difficult unless you add expiry, denylisting, or version checks. The practical result is that token lifetime becomes the main containment control, which is why long-lived JWTs create a wider compromise window.

Q: What do security teams get wrong about JWT headers?

A: They often treat JWT headers as trusted instructions instead of attacker-controlled data. Fields such as alg, jku, x5u, and kid can be abused if verification logic uses them without strict allowlists and sanitisation. The safer model is to pin verification behaviour in code and only accept headers that match that predeclared policy.

Q: How do teams reduce the risk of cross-token confusion in JWT-based systems?

A: Use different validation rules for different token classes and make them mutually exclusive. An access token should not pass as an ID token, a reset token, or a security event token. Strong audience checks, explicit token typing, and separate signing keys by purpose all help preserve workflow separation across identity use cases.

Technical breakdown

JWT structure, signatures, and claim validation

A JWT has three base64url-encoded parts: header, payload, and signature. The header says how the token should be verified, the payload carries claims, and the signature proves integrity. That signature does not encrypt the payload. Anyone who holds the token can read its contents, so sensitive data belongs elsewhere. Safe verification means checking more than signature validity. The verifier should pin the expected algorithm, confirm issuer and audience, enforce expiration and not-before rules, and reject tokens that do not match the application’s intended token type.

Practical implication: treat JWT verification as an explicit policy decision, not a library default.

Algorithm confusion and hostile JWT headers

JWT libraries can be tripped up when they trust the token header to choose verification behaviour. That is how algorithm confusion happens, for example when a token signed with one algorithm is reinterpreted as if it were signed with another. Header fields such as jku, x5u, and kid are also inputs, not trusted metadata. If a verifier fetches keys from attacker-controlled locations or treats kid as a database key without sanitisation, the token becomes a delivery mechanism for SSRF or injection instead of an identity control.

Practical implication: pin allowed algorithms and validate every header field as untrusted input.

Short-lived access tokens and revocation design

JWTs are stateless, which makes revocation harder than with server-stored sessions. The usual answer is shorter access-token lifetimes combined with refresh-token rotation, because refresh tokens can be stored and revoked server-side. That reduces the window in which a stolen token remains useful and provides a theft signal if the same refresh token is reused. Longer-lived JWTs create a governance problem, not just a technical one, because the system loses timely control over who can still use a valid token after a compromise or account change.

Practical implication: keep access tokens short-lived and design refresh handling as the revocable control point.

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

JWT validation is an identity control, not a transport detail. The guide makes clear that a token can be cryptographically valid and still be the wrong token for the service that receives it. That is an identity governance problem, not just an application bug, because the verifier is deciding who or what is allowed to act. Practitioners should treat JWT verification as a policy boundary with explicit rules for issuer, audience, type, and lifetime.

Header trust is a broken assumption in token-based authentication. JWT headers were designed to describe verification context, not to be trusted as instructions from the token itself. Once teams let the token select algorithms or key sources, they move from authentication to self-asserted authority. The practical conclusion is that token metadata must be treated as hostile input, especially in distributed systems where multiple services verify the same identity artefact.

Short-lived access tokens create a narrower blast radius than revocation-heavy designs. The article reinforces a central NHI governance pattern: stateless tokens are hard to revoke, so lifetime becomes the main containment lever. That aligns with OWASP-NHI and ZT-NIST-207 thinking, where the real control is not merely token issuance but the duration and scope of trust. Teams that extend JWT lifetimes are expanding the period in which compromise remains actionable.

Key management defines the trust boundary for every JWT in circulation. If signing keys are shared too widely, reused across environments, or stored without strong controls, any compromise becomes a token forgery problem. That is why JWT governance belongs alongside secrets management and NHI lifecycle controls. Security teams should map signing keys to ownership, rotation, and environment separation as part of the identity programme, not as an infrastructure afterthought.

Cross-token confusion is a governance failure across identity types. Access tokens, ID tokens, refresh tokens, and security event tokens may share claims, but they should not share validation logic or trust assumptions. When one token class can be replayed as another, the organisation has collapsed purpose separation. Practitioners should enforce mutually exclusive validation rules so each token type only authenticates the workflow it was issued for.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that detection without revocation still leaves a live exposure window.
• JWT governance belongs in the wider identity lifecycle conversation, which is why practitioners should pair token policy with the Guide to the Secret Sprawl Challenge.

What this signals

JWT programmes are increasingly part of the same control plane as secrets management and NHI governance, because signed tokens often depend on long-lived keys, refresh workflows, and service-to-service trust. The operational signal is clear: if token verification is inconsistent across services, identity drift will appear as application instability long before it looks like a breach. Teams should map JWT trust paths the same way they map privileged machine identities.

Token trust debt: when organisations allow tokens to remain valid longer than the business can confidently trust them, they accumulate a form of identity debt that shows up during incident response. That debt is amplified when signing keys, revocation logic, and audience checks are handled differently across product teams. A consistent policy model reduces that exposure across human and non-human access flows.

For practitioners

• Pin verification rules to explicit expectations Configure JWT verification to require the expected algorithm, issuer, audience, and token type for each endpoint. Do not let the token header decide how the service behaves.
• Treat header parameters as hostile input Validate jku and x5u against trusted issuer allowlists, and sanitise kid before any lookup or filter operation. Reject loopback, private ranges, and unexpected key locations.
• Shorten access-token lifetime Use brief access-token expirations and reserve refresh-token rotation for the revocable part of the session. That limits the damage window if a bearer token is stolen.
• Separate token classes by validation logic Make access-token, ID-token, and security-event-token checks mutually exclusive so one token type cannot be substituted for another across workflows.
• Protect signing keys as NHI assets Store signing material in a secrets manager, rotate keys on a defined schedule, and keep production, staging, and development keys separate.

Key takeaways

• JWTs fail when teams confuse cryptographic authenticity with application-level authorisation.
• The biggest risk is not token format alone, but the combination of weak claim validation, hostile headers, and long-lived trust.
• Security teams should pin verification rules, shorten token lifetime, and treat signing keys as governed NHI assets.

Key terms

• Json Web Token: A JSON Web Token is a compact signed container for claims that one system presents to another. The token proves integrity, but not confidentiality, so the payload is readable by anyone who holds it. In identity programmes, JWTs must be validated as policy objects, not treated as self-authorising credentials.
• Refresh Token Rotation: Refresh token rotation is the practice of issuing a new refresh token each time the old one is used and invalidating the previous value. It narrows the window for token theft and gives defenders a reuse signal. For JWT-based systems, it is one of the few practical ways to regain revocation control.
• 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.
• Token Audience: Token audience is the service or workflow a token was intended to authenticate. A valid token can still be wrong if the audience does not match the endpoint receiving it. Audience checks preserve purpose separation and stop one identity artefact from being reused across unrelated access paths.

Deepen your knowledge

JWT validation, token lifetime, and signing key governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity controls for APIs, services, or agent-driven workflows, it is worth exploring.

This post draws on content published by WorkOS: JWT best practices for secure authentication. Read the original.