JWE for sensitive tokens: what it changes for API and IAM security

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Raidiam's blog post: Encrypted tokens matter when JWTs carry sensitive claims, scopes, PII, or internal business data.

Why it matters: For IAM and API teams, the point is that signing alone protects integrity, not confidentiality, so sensitive token contents still need controls that limit who can read them.

Context

JSON Web Encryption is a way to encrypt token content so only the intended recipient can read it. In API and IAM architectures, that matters when tokens carry claims, scopes, user attributes, or other sensitive data that should not be visible to intermediaries, logs, proxies, or partner systems.

The governance gap is not whether a token is valid, but whether its contents remain confidential across every hop in transit. JWS proves integrity and authenticity, while JWE addresses disclosure risk, which makes token design an identity security decision as much as a protocol choice.

That distinction becomes more important when organisations share tokens across internal services, external partners, and identity flows where transport security alone does not prevent inspection or reuse of sensitive payload data.

Key questions

Q: When should organisations encrypt tokens instead of only signing them?

A: Organisations should encrypt tokens when the payload contains claims, scopes, user attributes, or internal data that would be harmful if exposed to intermediaries, logs, or partner systems. Signing proves integrity, but it does not hide content. If disclosure matters, JWE is the control that changes the risk model.

Q: Why do encrypted tokens matter in API and IAM architectures?

A: Encrypted tokens matter because APIs and identity systems often move sensitive context through multiple trusted and semi-trusted systems. Without encryption, anyone able to inspect the token path can read the payload even if they cannot alter it. JWE narrows who can see sensitive claims, which is a confidentiality control, not a replacement for transport security.

Q: What breaks when token confidentiality is not in place?

A: When token confidentiality is missing, sensitive claims can be exposed to gateways, logs, support tooling, or partner integrations that were never meant to read them. The result is unnecessary disclosure of identity data, internal business logic, or authorization context, even when the token remains valid and correctly signed.

Q: How should teams compare JWE and TLS in token security design?

A: TLS protects data in transit between endpoints, while JWE protects the token payload itself wherever it travels and whoever handles it. They solve different problems, so the question is not which one to use, but whether the token contents need protection beyond the transport layer. In many API and IAM flows, they are complementary.

Technical breakdown

JWE versus JWS: integrity and confidentiality solve different problems

JWS and JWE are often discussed together, but they solve different security objectives. JWS signs a token so the recipient can verify it has not been altered and can trust who created it. JWE encrypts the token so only the intended recipient can read the contents. In practice, a signed token may still expose claims to every system that handles it, including middleware, gateways, and observability tooling. That is why token design has to account for both authenticity and exposure risk, not just whether the payload can be trusted.

Practical implication: decide explicitly whether a token needs integrity only or both integrity and confidentiality.

How JWE protects sensitive claims in API and identity flows

A JWE token wraps the payload in five parts: protected header, encrypted key, initialization vector, ciphertext, and authentication tag. The authorization server typically encrypts a content encryption key with the recipient's public key, then encrypts the payload with that key. The recipient uses its private key to recover the content encryption key and decrypt the payload. That model is useful when request objects, ID tokens, access tokens, or partner messages contain data that should not be readable outside the receiving party. It also limits exposure if the transport path includes untrusted intermediaries.

Practical implication: use recipient-bound encryption whenever token contents include sensitive claims or business data.

Why token encryption changes the trust model for APIs and IAM

JWE changes the trust model by reducing who can inspect token contents, but it does not remove the need for key management, signing, or TLS. The article's examples show that confidentiality matters in OpenID Connect, OAuth 2.0, financial-grade APIs, and enterprise integrations because tokens can carry identity attributes, scopes, and internal claims that reveal more than many teams intend. The real issue is that modern token paths often cross systems that are not all equally trusted. Encryption narrows disclosure, but the surrounding governance still has to control where keys live and who can decrypt.

Practical implication: treat token encryption as a confidentiality layer that must be paired with secure key handling and transport protection.

Breaches seen in the wild

• Microsoft Storm-0558 key breach 2023: China-based Storm-0558 used a stolen, never-retired Microsoft signing key to forge tokens and read email at 22 organisations in 2023.
• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Token confidentiality is now part of access governance, not an optional transport detail. If a token carries claims, scopes, or PII, the security question is not only whether it is authentic but whether every intermediate system can read it. That shifts JWE from an implementation nicety to a governance control for API and IAM teams. The practitioner conclusion is simple: signed tokens are not sufficient when payload disclosure is itself a risk.

JWE addresses a disclosure problem that signing cannot solve. JWS protects against tampering and spoofing, but it leaves payload visibility intact. In distributed architectures, that means proxies, logs, partner hops, and support tooling may all see content that should stay private. The implication is that confidentiality boundaries have to be designed into token handling, not inferred from TLS alone.

Protected token payloads become more important as identity systems carry richer data. The more identity context, business logic, and authorization detail move into tokens, the more exposure occurs when those tokens are not encrypted. That is especially relevant in OpenID Connect and OAuth 2.0 patterns where claims can reveal user attributes and access scope. The practitioner takeaway is to classify token contents before deciding whether JWE is warranted.

Key management becomes the control plane for encrypted token trust. JWE does not eliminate the need to protect private keys, rotate encryption material, and control who can decrypt what. It moves the primary control point from payload visibility to key custody and recipient trust. The practitioner conclusion is that teams should govern encryption keys with the same discipline they apply to credential lifecycle controls.

Confidentiality by recipient design: JWE is most relevant when the intended reader of a token is narrow but the delivery path is broad. That makes it a useful pattern for partner APIs, high-assurance financial exchanges, and internal service chains that should not expose payload content to every intermediary. The practitioner conclusion is to use encryption where disclosure risk is the issue, not everywhere by default.

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: Token and Session Security Guide

What this signals

Token confidentiality has to be designed, not assumed. Once claims, scopes, or user attributes move inside JWTs, every proxy, log pipeline, and integration hop becomes part of the disclosure surface. Teams should treat encrypted token design as a governance decision tied to where identity data is allowed to be read, not just where it is allowed to be sent.

Encrypted token handling will increasingly sit alongside key lifecycle controls. JWE shifts the hard problem from token visibility to key custody, recipient trust, and rotation discipline. That means IAM and security teams need a clear operating model for decryption authority, especially where partner APIs and federated identity flows share sensitive data.

For practitioners

• Define which tokens require confidentiality Classify JWTs, request objects, and session-related tokens by the sensitivity of the claims they carry, then reserve encryption for payloads that expose identity attributes, scopes, or internal business logic.
• Separate signing requirements from encryption requirements Use signing to preserve integrity and authenticity, and add JWE when token contents should not be readable by intermediaries, logs, or partner systems.
• Protect private keys as production secrets Store decryption keys in managed key services or hardware-backed stores rather than source trees or project directories, and restrict decryption access to the smallest receiving set.
• Review token flows that cross trust boundaries Map every place a token can be inspected or forwarded, including gateways, proxies, and federation hops, then determine whether confidentiality needs to apply at each boundary.
• Validate algorithm choices and key rotation Use approved key management algorithms and content encryption methods, and pair them with rotation practices that reduce exposure if a key is compromised.

Key takeaways

• JWE adds a confidentiality layer to token design that signing alone does not provide, which matters when tokens carry sensitive identity or business data.
• The exposure risk is not limited to external attackers because intermediaries, logs, and partner systems can also inspect unencrypted token payloads.
• Teams need to pair token encryption with secure key custody and recipient-specific trust rules, or the confidentiality benefit will be incomplete.

Key terms

• JSON Web Encryption: JSON Web Encryption is a standard for encrypting JSON-based security objects so only the intended recipient can read the payload. In identity systems, it is used to keep claims, scopes, and other sensitive data confidential even when messages travel through intermediaries.
• JSON Web Signature: JSON Web Signature is the JOSE standard that defines how a token is signed to prove integrity and authenticity. It does not hide the token contents. Instead, it lets a verifier check whether the payload was altered after issuance and whether the token came from a trusted signing key.
• Content Encryption Key: A Content Encryption Key is the symmetric key used to encrypt the actual payload inside a JWE object. It is typically generated for a single token and then protected with the recipient’s key management method, which keeps the data encrypted while still enabling controlled decryption.
• Token Confidentiality: Token confidentiality is the property that keeps token contents unreadable to anyone other than the intended recipient. It matters when claims, scopes, or identity attributes would create risk if exposed to intermediaries, logs, or partner systems, and it is distinct from token validity or authenticity.

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 building or maturing an IAM programme, it is worth exploring.