JWT vs bearer tokens: what identity teams need to know

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Descope's blog post: JWTs and bearer tokens differ because one is a token format and the other is an authentication scheme.

Why it matters: IAM teams need this distinction because revocation, storage, and validation decisions affect risk far more than token syntax in API and OAuth/OIDC flows.

Context

JWT and bearer token are often used as if they mean the same thing, but they sit at different layers of the authentication design. A bearer token defines how a credential is presented, while a JWT defines how the token is structured and what claims it carries.

For identity teams, the practical issue is not vocabulary. It is whether the programme treats possession-based access, token storage, and token expiry as governance decisions in API, OAuth 2.0, and OpenID Connect flows.

Key questions

Q: How should security teams choose between JWTs and opaque tokens for APIs?

A: Choose JWTs when distributed validation, low latency, and stateless scale matter most. Choose opaque tokens when revocation speed, centralized session control, or claim privacy is more important. The right answer depends on how quickly access must be withdrawn and whether the API can tolerate server-side token lookup on each request.

Q: What happens when a bearer token is stolen or intercepted?

A: Whoever holds the token can usually act as the authorised user or service until the token expires or is revoked. That is why bearer tokens must be protected as credentials, not treated as harmless request metadata. Short lifetimes, secure transport, and safe storage are the controls that reduce the replay window.

Q: How do identity teams know JWT claims are being trusted safely?

A: They should verify that the token signature, issuer, audience, and expiration checks are enforced on every request path that accepts the token. If those checks vary by service, claims can be accepted outside their intended trust boundary, which turns a signed assertion into an over-broad access path.

Q: What is the difference between JWTs and bearer tokens in OAuth and OIDC?

A: In OAuth and OIDC, bearer describes how the credential is presented and JWT describes the token's internal structure. A JWT can be used as a bearer token, but it does not have to be. The distinction matters because transport security, revocation, and client storage are separate governance decisions.

Technical breakdown

Bearer tokens: possession equals access

A bearer token is an authentication scheme, which means the server authorises whoever presents the token without asking for a second proof such as a password or device binding. That makes it simple for APIs, but it also means the token itself becomes the security boundary. If it is intercepted, copied from insecure storage, or reused outside its intended context, the holder can act as the original user or service. In identity governance terms, the control problem is not the token name, but the absence of proof of possession and the reliance on token secrecy.

Practical implication: treat bearer tokens as high-value credentials and govern storage, transport, and expiry as first-class controls.

JWTs: claims inside a signed token

A JWT is a compact token format with a header, payload, and signature. The payload can carry claims such as user ID, roles, and expiration time, and the signature lets the receiver verify that the token has not been tampered with. That self-contained structure is why JWTs work well in distributed systems: the API can validate the token without calling back to a central session store on every request. The trade-off is governance complexity, because claims remain valid until expiry unless the surrounding architecture adds revocation or short-lived issuance patterns.

Practical implication: use JWTs only when the claim lifetime, signing model, and revocation approach are all explicitly designed.

JWT bearer flows: the risk is in the operating model

Most confusion comes from the common pattern of using a JWT as a bearer token in OAuth 2.0 and OpenID Connect. In that setup, bearer describes transmission and JWT describes format, so the same object carries both transport semantics and self-contained claims. That combination is efficient, but it shifts the burden to secure HTTPS transport, secure client storage, expiration handling, and refresh design. Opaque bearer tokens solve a different problem, because the server can revoke them centrally and keep sensitive state off the client. The architectural choice is therefore about governance and lifecycle, not token glamour.

Practical implication: choose JWT bearer tokens for scale and opaque bearer tokens for revocation and central control.

Threat narrative

Attacker objective: The attacker wants to reuse a stolen token to obtain authorised access without knowing the underlying password or secret.

1. Entry occurs when a valid bearer token is captured through insecure client storage, traffic interception, or reuse in an exposed integration.
2. Escalation happens when the token remains valid long enough to be replayed against protected API resources without any second factor or proof of possession.
3. Impact follows when the attacker uses the token's granted session or claims to access data, act as the user, or continue making authorised API calls until expiry or revocation.

Breaches seen in the wild

• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Token syntax is not the governance problem: JWT versus bearer token confusion persists because teams focus on format while the actual risk sits in transport, storage, revocation, and claim lifetime. A bearer token can be opaque or self-contained, and a JWT can be used inside that scheme. The practitioner mistake is treating string format as the security control instead of the identity lifecycle around the token.

Possession-based access creates a standing credential window: bearer tokens turn whoever holds the token into the authorised actor for as long as the token remains valid. That is acceptable only when the surrounding architecture assumes theft is possible and constrains exposure through short lifetime, secure storage, and tight audience control. The governance question is how much access is allowed to persist after the original issuance moment.

JWT bearer flows expose a revocation-versus-scalability trade-off: self-contained JWTs reduce lookup overhead, but they also delay central control over changes in status, role, or session validity. Opaque bearer tokens preserve more immediate revocation leverage because the server remains the source of truth. Identity teams should recognise this as an architectural decision about control latency, not just a developer preference.

Claims are not permissions unless the surrounding system makes them so: JWT payloads can describe identity attributes, but those attributes only become authoritative when the validation path, signing trust, and audience rules are correctly enforced. That makes the real control plane the combination of token issuer, verifier, and storage pattern. Practitioners should govern the trust boundary, not just the payload schema.

OAuth and OpenID Connect normalise bearer semantics, which makes weak handling look ordinary: because JWT bearer tokens are common in modern login flows, teams can mistake ubiquity for safety. The result is predictable risk accumulation in client storage, refresh design, and API validation. Identity programmes should treat these flows as a privileged credential distribution model, not just an implementation detail.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: NHI Authentication Guide

What this signals

JWT bearer tokens turn token handling into an access-governance problem: the format is only part of the control surface. Once a bearer token can be replayed by whoever holds it, identity teams need to manage storage, transport, expiry, and revocation as one lifecycle, not as separate technical chores.

Opaque tokens and self-contained JWTs answer different governance questions: opaque tokens favour central control and faster revocation, while JWTs favour distributed validation and fewer lookups. The right choice depends on whether the programme values control latency or scale more for the protected API estate.

For practitioners

• Define the token layer explicitly Document whether each API uses JWTs, opaque tokens, or both, and record whether the bearer scheme, not the token format, is carrying authorisation risk.
• Shorten bearer token lifetime Set expiration tightly enough that a stolen token has a limited replay window, and align refresh behaviour with the sensitivity of the protected API.
• Protect client-side token storage Keep bearer tokens out of insecure browser and application storage paths, and prefer storage patterns that reduce exposure to script access and accidental logging.
• Use opaque tokens where revocation matters Choose server-referenced opaque tokens when immediate logout, role changes, or session termination must take effect without waiting for token expiry.
• Validate issuer, signature, and audience Check that every JWT comes from a trusted issuer, has a valid signature, and is intended for the API that receives it before authorising the request.

Key takeaways

• Bearer tokens create risk because possession alone is sufficient for access, so token handling must be governed like credential management.
• JWTs solve a different problem from bearer tokens by packaging claims in a signed format that can be validated without a central lookup.
• Identity teams should choose token patterns based on revocation needs, trust boundaries, and storage risk, not on terminology confusion.

Key terms

• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• Jwt: A signed token format that packages claims in a compact structure made of a header, payload, and signature. It tells receivers what information is inside the token, but not how that token must be transported or stored.
• Opaque Token: An opaque token is a credential string that does not reveal its claims, scopes, or permissions when inspected directly. Security teams must query the issuer or correlate telemetry to understand what the token can do, which makes audit and right-sizing more difficult.
• 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.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.