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

At a glance

What this is: This is a practical explanation of JSON Web Encryption and how it protects sensitive token contents in transit.

Why it matters: It matters because IAM and NHI teams often rely on signed tokens alone, leaving claims, scopes, and other sensitive data readable to intermediaries.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Raidiam's guide to encrypting and decrypting JWTs with JWE

Context

JSON Web Encryption, or JWE, is the encryption layer in the JOSE family used to keep token contents confidential. In IAM and NHI environments, that matters when JWTs carry claims, scopes, user attributes, or system data that should not be readable by proxies, logs, or intermediate services.

The common failure mode is assuming that a signed token is sufficiently protected. JWS proves integrity, but it does not hide the payload, so any system that can inspect traffic may still see sensitive information. That gap shows up in federated identity, partner APIs, and non-human identity workflows where tokens move across multiple trust boundaries. For background on how NHIs expand this problem, see the Ultimate Guide to NHIs.

Key questions

Q: When should security teams use JWE instead of only signing tokens?

A: Use JWE when the token payload contains sensitive information that should remain confidential outside the intended recipient, such as claims, scopes, PII, or internal business data. Signing alone proves integrity, but it does not hide the payload. If intermediaries can inspect or store the token, encryption becomes a necessary additional control.

Q: What is the difference between JWE and JWS for identity teams?

A: JWS proves a token was not altered and identifies the signer. JWE keeps the token contents unreadable to anyone except the intended recipient. Identity teams often need both, because authentication workflows need integrity, while federated or partner-facing claims may also require confidentiality.

Q: How should teams manage JWE keys in production?

A: Treat JWE keys as governed cryptographic assets. Public keys should be registered correctly, private keys should stay in secure storage, and rotation should be tied to client lifecycle events and incident response. Weak key governance undermines confidentiality even when the encryption algorithm is sound.

Q: Why does JWE matter in OAuth and OpenID Connect flows?

A: OAuth and OpenID Connect tokens can carry sensitive claims, scopes, and identity context that may pass through proxies, logs, and partner systems. JWE protects the payload itself, which is useful when the transport path is not the only place exposure can occur. That makes it especially relevant in federated and multi-party integrations.

Technical breakdown

How JWE separates encryption from signing in token flows

JWE and JWS solve different problems. JWS signs a payload so the recipient can verify integrity and authenticity, while JWE encrypts the payload so only the intended recipient can read it. In practice, a token can be both signed and encrypted, which is common when an issuer wants to preserve non-repudiation while still hiding claims. The JWE compact form uses five parts: protected header, encrypted key, initialization vector, ciphertext, and authentication tag. That structure lets the receiver validate the algorithm choice, unwrap the content encryption key, and decrypt the ciphertext safely.

Practical implication: Use JWE whenever token content includes data that should not be visible outside the intended trust boundary.

Why public key handling is central to JWE security

JWE commonly uses asymmetric key management so the sender encrypts a content encryption key for the recipient’s public key, and only the private key can recover it. That design supports client-to-server, server-to-client, and multi-recipient use cases, but it also shifts risk to key lifecycle management. If public keys are registered incorrectly, rotated slowly, or tied to weak client onboarding, confidentiality degrades quickly. The encryption algorithm also matters. Strong defaults such as RSA-OAEP-256 and AES-GCM reduce downgrade risk, but only if implementation choices are enforced consistently across services.

Practical implication: Treat JWE as a key management problem as much as a cryptography problem.

JWE in OpenID Connect and OAuth 2.0 token exchange

In OpenID Connect and OAuth 2.0, encrypted tokens are most useful when identity claims, authorization context, or internal business data should be hidden from intermediaries. That includes ID tokens, request objects, and partner-facing payloads that may pass through logs, gateways, or message brokers. JWE does not replace TLS, because transport security protects the channel while JWE protects the object itself after it leaves the channel. That distinction is important in distributed architectures where data can be copied, forwarded, or cached outside the original session.

Practical implication: Encrypt the token when the payload itself is sensitive, not just when the transport path is risky.

Threat narrative

Attacker objective: The attacker aims to recover sensitive token contents that can be used for reconnaissance, abuse, or unauthorized access across identity and API workflows.

1. Entry occurs when sensitive claims or access scopes are embedded in a signed but unencrypted token and pass through systems that can inspect payloads.
2. Escalation happens when a proxy, logger, middleware layer, or partner integration captures readable token contents and reuses them for unauthorized access decisions.
3. Impact is the exposure of identity data, authorization context, or business-sensitive claims that should have remained confidential between issuer and recipient.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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

NHI Mgmt Group analysis

JWE is a token confidentiality control, not a general identity control. Encryption protects payload secrecy, but it does not solve privilege design, token lifetime, or client trust. Teams that treat JWE as a substitute for least privilege end up hiding weak authorization decisions instead of fixing them. The practical conclusion is simple: encrypt sensitive claims, then separately govern who can mint, inspect, and replay them.

Token confidentiality becomes a non-human identity issue as soon as APIs and agents exchange claims across trust boundaries. Service accounts, bots, and AI agents often consume tokens in machine-to-machine flows where payloads are copied into logs, brokers, and middleware. That broadens the exposure surface well beyond the client application. Practitioners should therefore review JWE as part of NHI governance, not just application security.

Protected headers and algorithm choices create a governance burden that many teams underestimate. The security of JWE depends on consistent enforcement of key algorithms, recipient keys, and decryption expectations. If teams allow algorithm sprawl or inconsistent client registration, they create avoidable failure modes. The operational answer is policy control over crypto choices, not ad hoc developer preference.

Zero Trust principles support JWE, but they do not eliminate the need for transport and logging controls. JWE secures the object after it leaves one boundary, while TLS protects the session and data loss controls reduce accidental disclosure elsewhere. Teams need all three layers when tokens carry sensitive claims. The governing principle is defense in depth, with JWE as one layer rather than the whole strategy.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why token confidentiality and lifecycle control need to be addressed together.
• For the broader identity control model, see Top 10 NHI Issues for the governance gaps that tend to surface alongside token exposure.

What this signals

Ephemeral token secrecy is now part of NHI governance. Once APIs, bots, and agents exchange claims across multiple systems, the question is no longer whether tokens are signed, but whether the payload can be inspected where it should not be. With NHIs outnumbering human identities by 25x to 50x, the scale of machine-held secrets and claims makes token confidentiality a programme issue, not a developer preference.

JWE should be evaluated alongside logging, data minimisation, and trust boundary design. If a middleware layer can still read the content, the organisation has only moved the exposure point, not removed it. Teams that already align to OWASP Non-Human Identity Top 10 can map encrypted-token use to overprivilege, secret exposure, and weak lifecycle control more cleanly.

Identity payload shielding: the operational value of JWE is highest when claims move through federated systems, partner APIs, and service-to-service workflows that do not share the same trust boundary. That makes encryption a complement to least privilege and zero trust, not a replacement for either.

For practitioners

• Encrypt sensitive claims, not every token by default Reserve JWE for tokens that contain PII, scopes, internal attributes, or other payload data that should not be readable outside the recipient. Avoid blanket encryption if it adds complexity without reducing real exposure.
• Separate signing policy from encryption policy Require teams to define when JWS is enough and when JWE is mandatory. Document the data classes, trust boundaries, and APIs that trigger encryption so decisions do not vary by team or implementation.
• Harden recipient key lifecycle controls Register, rotate, and retire public keys with the same discipline used for other cryptographic material. Tie key changes to client onboarding, offboarding, and incident response processes.
• Review logs and middleware for token disclosure Check whether gateways, message brokers, observability tools, or debug logs can still read token payloads before encryption is applied. If they can, JWE should be evaluated alongside logging suppression and data minimisation.

Key takeaways

• JWE addresses confidentiality, while JWS addresses integrity, so IAM teams should choose based on what the token contains and who can inspect it.
• The main operational risk is not cryptography alone, but weak key lifecycle control, inconsistent recipient registration, and unreadable assumptions about intermediaries.
• For NHI governance, the right response is to classify sensitive token payloads, encrypt where needed, and keep signing, transport, and logging controls in separate lanes.

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.
• 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.
• Authentication Tag: An Authentication Tag is the integrity check attached to encrypted content so the recipient can confirm the ciphertext was not altered. In JWE, it supports tamper detection after decryption and helps distinguish valid encrypted content from manipulated or corrupted messages.
• Recipient Public Key: A Recipient Public Key is the encryption key used to protect the content encryption key for a specific recipient. In practice, this lets the sender encrypt token content for one or more intended parties without exposing the private key required to decrypt it.

Deepen your knowledge

JWE for sensitive tokens and federated identity flows are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are formalising token governance across APIs and machine identities, it is worth exploring.

This post draws on content published by Raidiam: JSON Web Encryption explained with Java examples and best practices. Read the original.