Why do JWTs create risk when used as bearer tokens?

Why This Matters for Security Teams

JWTs are often treated as “safe” because they are signed, but signature validity only proves the token was issued by a trusted party. It does not stop replay if the token is copied, intercepted, or reused outside the intended session. When a JWT is used as a bearer token, possession becomes authorization, so leakage turns into immediate account or workload impersonation.

That risk is visible in real incidents where secrets and tokens are exposed far outside intended storage. NHIMG’s research on The 2025 State of NHIs and Secrets in Cybersecurity found that 44% of NHI tokens are exposed in the wild, including Teams, Jira, Confluence, and code commits. The broader lesson aligns with the NIST Cybersecurity Framework 2.0: credential handling is part of resilience, not an afterthought.

In practice, many teams discover bearer-token replay only after logs, browser storage, or a build artifact has already leaked the token and been used from somewhere unexpected.

How It Works in Practice

A JWT becomes risky as a bearer token because anyone who presents it can usually act as the subject until it expires. The cryptographic signature helps the resource server verify integrity and issuer trust, but it does not bind the token to a specific device, TLS session, or human. That means a copied JWT can be replayed from a different network, automation job, or attacker-controlled host.

Security teams reduce this risk by treating JWTs as short-lived, tightly scoped credentials rather than durable session keys. Good practice is to combine transport protection, minimal claims, and fast revocation paths with storage controls that keep tokens out of browser local storage, query strings, and verbose application logs. Where possible, use audience restriction, token rotation, and narrower lifetimes so exposure windows are small.

For high-risk workloads, current guidance suggests moving beyond simple bearer semantics. That can include sender-constrained tokens, proof-of-possession patterns, mTLS-bound sessions, or workload identity approaches that prove what the caller is, not just what it holds. The Guide to the Secret Sprawl Challenge shows why secret proliferation matters: if the same token appears in too many places, incident response becomes a race against replication. The same control logic is reflected in OAuth guidance from the IETF, which continues to distinguish bearer use from stronger sender-constrained designs.

• Keep JWTs short-lived and rotate them automatically.
• Store them only in controlled runtime memory when possible.
• Never place them in URLs, tickets, or chat systems.
• Validate issuer, audience, expiry, and intended scope at every request.
• Prefer stronger token binding for higher-risk APIs and automation.

These controls tend to break down in browser-based single-page apps with long user sessions and third-party scripts because token exposure paths multiply faster than revocation can keep up.

Common Variations and Edge Cases

Tighter token binding often increases implementation overhead, requiring organisations to balance replay resistance against developer friction and operational complexity. That tradeoff is especially visible when teams need compatibility across mobile apps, legacy APIs, and third-party integrations.

There is no universal standard for every JWT deployment yet. Some environments can tolerate bearer tokens if lifetimes are very short and the blast radius is low. Others, especially customer-facing or privileged automation paths, should treat bearer replay as an unacceptable design choice. In those cases, the right answer is often not “better storage” alone but a different identity pattern.

This is where Salesloft OAuth token breach is a useful warning: once a token can be reused outside its intended context, the attacker does not need to defeat the signature, only obtain the token. For governance, map JWT handling to threat models in the NIST Cybersecurity Framework 2.0 and treat every storage location as a potential compromise point.

The practical exception is controlled service-to-service traffic with strict network segmentation and automated rotation, where short-lived bearer JWTs may be acceptable if exposure channels are tightly constrained.

Related resources from NHI Mgmt Group

• Why do third-party connector patterns create NHI risk even when tokens are refreshed automatically?
• Why do brokered access tokens still create identity risk?
• Why do exposed JWTs and API tokens create such high risk?
• Why do bearer tokens create replay risk in distributed systems?