What is the difference between JWS and JWE in JWT implementations?

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.

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?