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

Why This Matters for Security Teams

JWTs and opaque tokens are often treated as a simple implementation choice, but the decision shapes how fast access can be revoked, how much identity data is exposed to clients, and how much operational load lands on the API tier. That matters most for NHI and agentic workloads, where tokens are frequently issued to services, scripts, and autonomous agents rather than people. A token that is easy to validate can still be dangerous if it stays usable after compromise, as seen in incidents like the Salesloft OAuth token breach.

Security teams also need to account for secret sprawl and token exposure outside code. NHIMG research reports that 44% of NHI tokens are exposed in the wild, including in chat tools, tickets, and code commits, which means token format alone does not solve leakage. Current guidance from the NIST Cybersecurity Framework 2.0 suggests aligning token strategy to risk, not convenience. In practice, many security teams discover the revocation problem only after a token has already been copied into places that are hard to clean up.

How It Works in Practice

JWTs are best when an API needs local verification at scale. The resource server can validate the signature, inspect claims, and make an allow or deny decision without calling a central authorization service on every request. That reduces latency and removes a dependency, which is useful for distributed systems, gateways, and microservices. Opaque tokens work differently: the token is just a reference, and the API or authorization layer looks it up against an introspection endpoint or session store to recover the active policy state.

That distinction drives real operational tradeoffs:

• Use JWTs when the API must validate offline, tolerate intermittent auth service outages, and scale across many services.
• Use opaque tokens when revocation must be immediate, session state must be centralized, or claims should not be visible to the client.
• Use short token lifetimes either way, because long-lived credentials expand blast radius after exposure.
• Prefer refresh flows and explicit token rotation rather than assuming expiry alone will contain risk.

This is especially important for NHI-heavy environments, where tokens are often reused by pipelines, integrations, and automation. NHIMG’s Guide to the Secret Sprawl Challenge and State of Secrets Sprawl 2026 both show that exposure is frequently about lifecycle failure, not just weak storage. For governance, the NIST Cybersecurity Framework 2.0 remains a solid reference for access control and continuous monitoring. These controls tend to break down in high-throughput legacy APIs that cannot afford per-request introspection but still require near-real-time revocation.

Common Variations and Edge Cases

Tighter token control often increases latency and operational overhead, so teams have to balance revocation speed against service complexity. That tradeoff becomes sharper when tokens carry sensitive claims, when APIs are public-facing, or when regulators expect rapid access withdrawal after offboarding or compromise.

One common edge case is using JWTs with very short TTLs and a revocation list. That can work, but there is no universal standard for how fresh revocation checks must be, and the design can drift toward opaque-token behaviour once introspection is added. Another edge case is hybrid architectures: a gateway may accept JWTs for internal routing, while the backend still enforces token status through a centralized session store. That is often the right compromise when performance matters but post-issue invalidation still has to be controlled.

Opaque tokens are usually the safer choice when claim privacy matters or when tokens may be copied into logs, support tools, or browser storage. JWTs are usually better when distributed services must validate locally and the claims are small, stable, and non-sensitive. The right answer changes quickly in environments with frequent offboarding, third-party integrations, or autonomous workflows that can chain API calls faster than a human can respond.

For teams managing NHI sprawl, the practical question is not which token type is more modern, but which one can be revoked, rotated, and observed before an exposed credential becomes reusable across systems.

Related resources from NHI Mgmt Group

• How should security teams choose between short-lived access tokens and refresh tokens?
• How should security teams choose between OAuth flows for different client types?
• How should security teams choose between hardware and software tokens for MFA?
• How should security teams choose between passwords, tokens, certificates, and biometrics?