JWT security best practices fail when tokens outlive context

At a glance

What this is: This is an analysis of why JWTs fail in practice when valid tokens are treated as portable trust artefacts instead of context-bound credentials.

Why it matters: It matters because IAM and security teams need to control token validation, storage, scope, and lifecycle across distributed services rather than assuming signature validity is enough.

Context

JWTs are signed identity payloads used to move trust between distributed services without server-side session state. That design is useful, but it also means each service must validate not just the signature but the token's issuer, audience, lifetime, and intended use.

The security problem is not the token format itself. It is the gap between how JWTs are issued and how they are reused, stored, and accepted across systems that often treat any valid token as broadly trustworthy.

Key questions

Q: What breaks when JWT claims are checked before signature validation?

A: If claims are checked before signature validation, an attacker can supply a token that looks correct but was never issued by a trusted source. That can produce false positives for roles, audience, or expiry and turn a forged object into accepted identity evidence. The failure is policy without proof, which is not a safe authorisation model.

Q: Why do JWT claims create risk when each service handles them differently?

A: JWT claims become risky when services parse, trust, or transform them in different ways. Inconsistent audience checks, issuer checks, and clock-skew handling can produce different authorisation outcomes for the same token. Centralised validation removes that drift and gives identity teams one place to enforce trust decisions.

Q: How do security teams know whether JWT validation is actually working?

A: They should test the full token lifecycle, including expired tokens, altered signatures, wrong issuers, wrong audiences, and algorithm confusion cases. If any of those tokens are accepted, the validation model is not trustworthy. Validation must be consistent across services, not just correct in one gateway or library.

Q: Should teams treat JWTs like session cookies or like bearer credentials?

A: They should treat JWTs like bearer credentials with explicit trust boundaries, not like harmless session metadata. A valid token can be replayed, reused, or accepted outside its intended context, so the governance model must assume exposure, scope drift, and downstream misuse are all possible.

Technical breakdown

Signature verification and algorithm handling

A JWT is only as trustworthy as the validation path that accepts it. If a service decodes a token without verifying the signature, or accepts the algorithm declared by the token instead of enforcing an expected signing method, the payload becomes editable or the trust decision becomes attacker-influenced. That is why “valid-looking” tokens can still be unsafe: the crypto may be sound, but the implementation is not. The right model is explicit verification, explicit algorithm selection, and no fallback paths that weaken assurance.

Practical implication: enforce strict signature and algorithm validation on every service that accepts JWTs.

Token scope, audience, and cross-service reuse

JWTs are often issued for one API or workflow, then accepted elsewhere because the signature checks out. That turns a bounded credential into a portable bearer artifact that can travel farther than intended. Without audience and issuer binding, a token can be valid in one system and wrongly trusted in another. This is a governance problem as much as a technical one: the trust boundary is no longer the issuing system, it is every downstream service that chooses to accept the token.

Practical implication: bind each token to a specific audience and issuer, and reject cross-service reuse by default.

Stateless lifecycle control and revocation

JWTs are stateless, which means they do not naturally support server-side invalidation once issued. That creates an exposure window that lasts until expiry, and it becomes worse when tokens are long-lived, stored insecurely, or renewed without control. Revocation therefore has to be engineered back into the architecture through short lifetimes, refresh rotation, and selective invalidation mechanisms. The central design issue is that a valid token may remain exploitable long after the context that justified it has changed.

Practical implication: shorten token lifetimes and design a revocation strategy before tokens are deployed at scale.

Threat narrative

Attacker objective: The attacker wants to reuse a valid JWT to obtain unauthorized access across services and move beyond the token's original scope.

1. Entry occurs when an attacker obtains a JWT from insecure storage, logging, or another exposed path and can replay it without needing the user's primary credentials.
2. Credential access succeeds because the token is accepted as a portable trust artifact, even when it was issued for a narrower context or a different service.
3. Escalation follows when the token is reused across services that do not enforce audience, issuer, or algorithm constraints, expanding what the attacker can reach.
4. Impact is unauthorized access to downstream APIs and data that appear legitimate at the request level but were never meant to be accessible through that token.

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 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

JWT validation is a trust-boundary problem, not a token-format problem. The article is right to treat JWTs as cryptographically sound when implemented correctly, because the real failure is governance across services that independently decide what a token means. Once a token becomes portable proof, validation discipline has to be uniform. Practitioners should treat the trust decision as distributed policy, not a one-time signing event.

Cross-service token reuse creates identity blast radius. A JWT that works beyond the service or workflow for which it was issued becomes a shared credential in practice, even if nobody intended it to be one. That enlarges the attack surface in the same way credential reuse does in NHI estates: one artifact, many possible trust decisions. Teams need to understand that audience binding is a containment control, not an optional claim check.

Long-lived tokens create standing privilege in token form. Stateless design removes easy server-side revocation, so the risk window is defined by expiry, renewal, and storage exposure rather than by a central kill switch. The longer a token lives, the more likely it is to outlast the context that justified it. IAM programmes should treat token lifetime as a privilege-duration decision, not just an authentication setting.

Runtime visibility is now part of JWT governance. Static validation alone cannot show where a token is actually accepted, reused, or silently over-trusted after issuance. That creates a blind spot for service-to-service and automation-heavy environments, where the same token may be handled by several systems before anyone notices scope drift. Practitioners should expect token telemetry to become a core control surface, not a nice-to-have observation layer.

JWT governance is converging with broader NHI control patterns. The same discipline used for service accounts, API keys, and other non-human credentials applies here: bound scope, constrained lifespan, and clear ownership of trust decisions. The named concept here is token context drift, where a valid credential is accepted outside the purpose for which it was issued. That drift is what teams must design against.

What this signals

Token context drift: JWT governance fails when a service treats a valid token as universally trustworthy after issuance. The practical shift is from checking whether the token is signed to checking whether it is still appropriate for this service, this audience, and this moment.

Distributed systems make token misuse hard to see because each validation step can look correct in isolation. The control gap is not just weak crypto, but fragmented trust decisions across services that allow reuse to accumulate into access expansion.

For practitioners

• Enforce explicit signature verification Reject any JWT that is only decoded or that falls back to an untrusted algorithm path. Make the expected signing algorithm and verification key set explicit in every validating service.
• Bind tokens to intended context Validate audience and issuer on every request so a token issued for one workflow cannot be accepted by another service simply because the signature is valid.
• Shorten token lifetime by design Use short-lived access tokens and controlled renewal so exposed tokens stop being usable quickly, and avoid relying on indefinite stateless validity.
• Control token storage and transport Keep tokens out of logging paths and other environments where they can be inspected or replayed, and review transport patterns for accidental exposure.
• Add runtime visibility for token reuse Track where tokens are accepted across APIs and workflows so unexpected reuse, scope drift, or unplanned downstream access can be identified.

Key takeaways

• JWT failures usually come from validation and context errors, not from the JWT format itself.
• The operational risk grows when tokens are reused across services or allowed to live longer than the context that issued them.
• Strong JWT governance depends on verification, audience and issuer binding, short lifetimes, and runtime visibility into reuse.

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.
• Audience Binding: A control that limits a token to a specific downstream resource or service. It prevents credential replay across tools and keeps delegated access aligned to the exact action the system was allowed to perform.
• Token Revocation: Token revocation is the ability to invalidate a credential before its natural expiry when it is exposed, misused, or no longer needed. For JWTs and other NHI credentials, revocation closes the gap between detection and continued access, which is essential when a stolen token can otherwise remain usable.
• Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.

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.