JWS is the signing layer used to protect integrity and authenticity, while JWE is the encryption layer used to protect confidentiality. A signed token can still be read by anyone who has it, but only the holder of the right decryption key can inspect an encrypted token. In practice, teams often need JWS for verification and JWE only when claims must be hidden.
Why This Matters for Security Teams
JWS and JWE are often discussed as if they are interchangeable JWT features, but the operational impact is very different. JWS proves a token was issued by a trusted party and has not been altered, while JWE hides the contents from anyone without the decryption key. That distinction matters whenever a JWT crosses systems, is logged, or is inspected by intermediaries. Teams that only think in terms of “token security” often miss whether they need integrity, confidentiality, or both.
For identity-heavy environments, the risk is not abstract. Secrets and tokens frequently appear in service-to-service flows, which is why NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is useful background on why non-human credentials need tighter handling than human sessions. NHIMG research also notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why token misuse is so hard to spot once claims are exposed.
In practice, many security teams discover the difference only after a token has been forwarded to a place it should not have been read at all.
How It Works in Practice
Think of a JWT as a container and JWS or JWE as different protection layers applied to that container. With JWS, the payload remains readable, but the signature lets the recipient verify authenticity and integrity. With JWE, the token contents are encrypted so only the intended recipient can decrypt and inspect them. In many implementations, teams use JWS when a downstream service must validate claims and JWE when those claims contain sensitive data such as identifiers, scopes, internal routing hints, or embedded context that should not be exposed to intermediaries.
Operationally, the choice depends on who needs to read the token and where it travels. A gateway, API, or microservice mesh may only need signed claims to make an allow or deny decision. If the token may pass through proxies, logs, or shared infrastructure, encryption becomes more important. Guidance from the NIST Cybersecurity Framework 2.0 is directionally useful here because it emphasizes protecting data in transit and constraining access to sensitive information. For identity governance context, NHIMG’s Microsoft Azure Key Breach illustrates how quickly exposed credentials become a broader access problem when token material is not tightly controlled.
- Use JWS when recipients must validate issuer trust and claim integrity.
- Use JWE when claim confidentiality matters beyond the intended recipient.
- Use both when a token must be verifiable and private.
- Keep key management separate for signing and encryption to reduce blast radius.
These controls tend to break down in distributed systems with overly broad logging, shared decryption keys, or service meshes that require many intermediaries to inspect claims.
Common Variations and Edge Cases
Tighter token protection often increases implementation complexity, so teams have to balance confidentiality against operational overhead. That tradeoff becomes most visible when multiple services need to make routing or authorization decisions from the same token.
One common pattern is signed JWTs inside encrypted transport, which may be enough if the token never leaves a trusted boundary. Another is nesting a JWS inside a JWE, which preserves verifiable claims while hiding them from intermediate systems. Current guidance suggests using this pattern only when there is a clear confidentiality requirement, because it adds key-handling complexity and can complicate troubleshooting.
Edge cases usually involve ecosystems that rely on token introspection, centralized gateways, or third-party processors. If every downstream party needs to inspect the claims, encryption can become counterproductive unless the architecture is redesigned. If the token is only a reference and not a self-contained credential, JWE may add little value. The practical rule is simple: sign when integrity matters, encrypt when secrecy matters, and do both only when the deployment path truly requires it.
Where this guidance breaks down is in legacy integrations that expect readable claims everywhere, because encryption then conflicts with the very services that must enforce access decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | JWT handling affects non-human credential exposure and token misuse. |
| NIST CSF 2.0 | PR.DS-2 | JWE is about protecting data in transit and limiting token disclosure. |
| NIST SP 800-63 | AAL2 | JWT assurance depends on proof strength and trusted token validation. |
| NIST Zero Trust (SP 800-207) | SC-7 | Signed and encrypted tokens support trust boundaries in zero trust designs. |
| NIST AI RMF | Token integrity and confidentiality support governed, accountable identity use. |
Document token protection choices and monitor for misuse as part of AI/identity risk governance.
Related resources from NHI Mgmt Group
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between zero trust for users and zero trust for NHIs?
