Why do JWTs create risk when teams try to store permissions inside the token?

JWTs are static once issued, so any roles, scopes, or resource lists inside them can become stale before the token expires. If a user is downgraded, suspended, or moved to a different team, the token may still grant access. Because JWTs are also coarse-grained, they are a poor fit for real-time or fine-grained decisions.

Why JWT Permission Claims Become a Security Problem

JWTs are useful as compact proof of authentication, but they become risky when teams use them as a place to cache authorisation decisions. Once issued, a token cannot be updated in place, so any embedded roles, scopes, or entitlements may outlive the business change that should have removed them. That creates a gap between identity truth and access truth, especially in environments where people move roles, service accounts are reused, or access is revoked urgently.

This is why JWTs should be treated as a transport mechanism, not an access policy store. When permissions are baked into the token, security teams lose the ability to respond in real time to offboarding, privilege reduction, or suspected compromise. The problem is not the token format itself, but the false assumption that a signed claim set is equivalent to current authorisation. NHIMG’s research on token exposure shows how often stale credentials become operational risk, including the 2025 State of NHIs and Secrets in Cybersecurity finding that 91% of former employee tokens remain active after offboarding.

In practice, many security teams discover this only after a user has already been downgraded or suspended and the old token still works for hours or days.

How JWTs Should Be Used in a Safer Access Model

The safer pattern is to keep JWTs narrow: use them to assert identity, token issuer, audience, and a short-lived session context, then perform authorisation against live policy at the point of request. That lets the application check whether the user or workload is still allowed to perform the action right now, instead of trusting stale permission data embedded at login time. Current guidance from NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both align with this least-privilege, continuously evaluated approach.

For high-risk systems, teams should combine short token TTLs with central policy checks, revocation hooks, and audience restrictions. In practice, that means:

• Keep JWT claims minimal and avoid storing entitlements that change often.
• Validate permissions against the source of truth at request time.
• Use short expirations so stale access dies quickly.
• Revoke sessions or downstream secrets when roles change or an account is disabled.
• Reserve coarse token claims for routing or session context, not final approval.

This model is especially important for APIs, admin workflows, and machine-to-machine access, where a token may be replayed far beyond the original login event. NHIMG research also shows how quickly token-based exposure becomes operationally real, as seen in the Salesloft OAuth token breach, where exposed tokens enabled access that should not have survived the initial compromise. These controls tend to break down in legacy monoliths and offline edge systems because they cannot call a live policy engine before every sensitive action.

Where Teams Still Get This Wrong

Tighter token controls often increase engineering and operational overhead, requiring organisations to balance simpler application code against stronger revocation and policy enforcement. The main tradeoff is speed versus freshness: teams like JWTs because they are stateless and easy to validate, but that convenience becomes a liability when access must change quickly. Best practice is evolving, but there is no universal standard that says a JWT may safely contain long-lived permissions for every application.

Common edge cases include long-lived refresh patterns, multi-service SaaS estates, and integrations that cannot tolerate a live authorisation lookup on every call. In those environments, teams should reduce the blast radius by limiting claim scope, shortening expiry, and separating session identity from entitlement decisions. If a token must carry some permission context, treat it as advisory and re-check the most sensitive actions against current policy.

Security teams also need to watch for leakage outside the browser or API boundary. Tokens copied into tickets, logs, chat, or CI pipelines often persist long after the original session ends, which is why NHIMG’s Guide to the Secret Sprawl Challenge remains relevant to JWT governance as well. In practice, the failure mode appears when a stateless token is treated as a permanent permission record instead of a temporary proof of prior authentication.

Related resources from NHI Mgmt Group

• Why do JWTs create more risk when teams embed authorization logic directly into the token?
• Why do SAML assertions create recurring authentication risk for identity teams?
• Why do AI agents and copilots create more risk when they inherit broad enterprise permissions?
• Why do employees who change roles create access risk if permissions are not updated quickly?