When should organisations encrypt tokens instead of only signing them?

When encryption is the right response, not just signing

Tokens should be encrypted when disclosure of the token content would create its own security problem. That usually means the token carries claims that are sensitive in context, such as role scopes, internal entitlements, user attributes, tenant data, or partner-only business details. In those cases, integrity alone is not enough, because a signed token can still be read by every hop that handles it.

For OAuth-style ecosystems, the practical distinction is simple: signing protects authenticity and tamper detection, while encryption protects confidentiality. A token that only needs to prove who issued it can often remain signed. A token that might traverse untrusted middleware, shared logs, brokered integrations, or third-party systems should be assessed for JWT handling with confidentiality in mind, and where the claims are meant to stay private, JWE is the mechanism that changes the exposure profile.

That distinction matters most when the token is being used as a carrier of business meaning, not just an authentication artefact. If the payload reveals enough to assist privilege mapping, tenant enumeration, replay planning, or partner inference, then a signed-only token can leak more than teams expect even when the cryptography is correct.

What changes when the token crosses trust boundaries

The main trigger for encryption is not the existence of a token, but the path it takes. Tokens are commonly forwarded through API gateways, reverse proxies, observability tools, support systems, and partner runtimes. If any of those components can inspect the payload, then the token is effectively readable by each of them unless it is encrypted end to end.

That is why implementation details matter. A signed token may be perfectly adequate inside a tightly controlled first-party boundary, but the same design becomes weaker when the token is copied into browser storage, embedded in federation flows, logged for troubleshooting, or passed to downstream services that do not need to know the original claims. For sender-constrained or audience-restricted designs, you still need to decide whether the content itself should be confidential in transit as well as authentic.

When teams use encrypted tokens well, they are usually solving a very specific problem: reduce the number of places where claims can be read without breaking the ability of the receiving service to process them. That is a narrower and more defensible goal than “encrypt everything,” and it keeps the control tied to actual exposure.

See also RFC 8705 for certificate-bound access tokens and RFC 9449 for proof-of-possession tokens, both of which reduce replay risk but do not by themselves hide token contents.

How to decide whether signing alone is sufficient

The decision comes down to who must be able to read the payload, not just who must be able to validate it. If every intermediary is trusted, every log path is controlled, and the claims are non-sensitive, signing alone is often enough. If any of those assumptions fail, encrypted tokens deserve serious consideration.

API Key Management Guide is useful here as a parallel control pattern: the same judgment applies to bearer material generally. If exposure would reveal enough to misuse the token, shorten its lifetime, reduce its scope, or encrypt the payload before it reaches systems that do not need to inspect it.

Ultimate Guide to NHIs also reinforces the practical point that tokens often function as identity-bearing material, which means content exposure can become an access problem as much as a data problem. The more a token describes authority, the less comfortable you should be leaving it plaintext outside the smallest possible trust boundary.

Risk and Threat Considerations

Plain signed tokens can become an information leak even when no one forges them. If a token contains claims, scope hints, internal identifiers, or partner-specific attributes, those details may be harvested from logs, browser traces, message queues, or compromised intermediaries and then reused for reconnaissance or privilege mapping.

Failure mechanism: Teams rely on signature verification for safety, but signing only proves integrity. Any system that can observe the token can still read the payload, so confidentiality fails wherever the token crosses an untrusted or weakly governed hop.

Impact: The exposure can reveal tenant structure, entitlement model, internal routing, or sensitive user context, which increases the blast radius of any later compromise and can simplify replay, targeting, or partner abuse.

Practitioner Guidance

What to verify: Check whether the receiving service truly needs to read every claim in the token. If a downstream system only needs to confirm authenticity or audience, that is a signal to minimise payload content rather than add more visible claims.

Decision rule: If the token would be harmful to disclose to logs, intermediaries, or partner systems, encrypt it. If the token is only sensitive because of long lifetime or broad scope, address those issues too, because encryption does not fix overprivilege or replay risk by itself.

Common mistake: Treating “signed” as equivalent to “protected.” In practice, many breaches and exposure events happen because teams assume transport or signature protection also hides the payload, when it does not.

Practitioner takeaway: Use signing for authenticity and encryption for confidentiality, and require the stronger control whenever the token content itself would meaningfully change the risk if exposed.

Related resources from NHI Mgmt Group

• When should organisations fetch provider tokens at runtime instead of storing them in their own database?
• What are the implications of using OAuth tokens in third-party integrations?
• What makes OAuth tokens risky in NHI environments?
• What common vulnerabilities do cloud applications face with OAuth tokens?