Cybersecurity glossary
What is JSON Web Encryption (JWE)?
Learn what JSON Web Encryption (JWE) is, how compact and JSON serializations protect JWT claims, when to encrypt tokens, and which pitfalls still break JWE security.
Definition
JSON Web Encryption (JWE) is a JOSE standard for encrypting content—often JWT claims—so that only intended recipients with the correct keys can recover the plaintext, providing confidentiality in addition to (or instead of) a standalone signature.
Why JWE matters
Signed JWTs are portable and transparent. That transparency is a feature for interoperability—and a liability when payloads carry emails, roles, tenant secrets, or health identifiers. JSON Web Encryption (JWE) adds confidentiality so claim plaintext is recoverable only by intended recipients.
Teams reach for JWE when tokens travel through browsers, mobile storage, shared logging pipelines, or multi-hop brokers where “encrypted in transit” is not the same as “unreadable by the bearer.”
What JWE protects
Confidentiality
Ciphertext hides claims from anyone lacking decryption capability.
Integrity of ciphertext
Authenticated encryption modes detect tampering of the encrypted payload.
Recipient targeting
Key encryption wraps a CEK for specific recipient public keys or shared secrets.
Optional nested signing
A signed JWT can be the plaintext inside JWE for end-to-end authenticity.
Compact JWE construction
Choose algorithms
Select key management and content encryption algorithms allowed by policy.
Generate a CEK
Create a fresh content encryption key for this token instance.
Encrypt the CEK for recipients
Wrap the CEK with each recipient’s key encryption material.
Encrypt the payload
Encrypt plaintext claims (or a nested JWS) with the CEK and produce an auth tag.
Serialize five segments
Assemble protected header, encrypted key, IV, ciphertext, and tag.
Recipient decrypts and validates
Unwrap CEK, decrypt, then validate nested signatures and JWT claims as required.
JWE vs JWS at a glance
| Property | JWS | JWE |
|---|---|---|
| Primary goal | Integrity and authenticity | Confidentiality (plus AEAD integrity) |
| Payload readable? | Yes (base64url decode) | No without decryption keys |
| Typical JWT default | Signed access/ID tokens | Used when claim privacy is required |
| Key material | Signing private / verify public | Recipient decrypt keys / CEK wrap |
Security practices for JWE deployments
- Allowlist modern algorithms; reject deprecated or attacker-selectable weak suites.
- Prefer nested signed-then-encrypted JWTs when you need both authenticity and secrecy.
- Minimize sensitive claims even inside JWE—encryption is not a license for oversharing.
- Manage recipient keys via JWKS/KMS with rotation and clear ownership.
- Do not treat JWE as a substitute for authorization checks after decryption.
- Avoid logging compact JWE strings if decryptors or CEKs could be nearby in the same system.
- Test failure modes: wrong recipient, algorithm confusion, and truncated authentication tags.
- Remember TLS still matters for transport integrity between hops.
The practical takeaway
JWE encrypts JOSE content so JWT claims are not world-readable. It solves confidentiality problems that signatures alone cannot.
Use it when claim privacy is a real requirement, combine it with sound authenticity controls, and keep algorithm and key management as strict as for signed tokens. For integrity-focused tokens without encryption, see JSON Web Signature (JWS).
Related security terms
JSON Web Signature (JWS)
Integrity and authenticity protection that JWE complements with confidentiality.
JWT (JSON Web Token)
Claims tokens that may be signed (JWS) and optionally nested inside JWE.
JSON Web Key (JWK)
Key representation used to encrypt content encryption keys for recipients.
Access Token
API credentials that sometimes use JWE when claim privacy is required.
JSON Web Token (JWT) Attacks
Validation failures that still matter when encryption is misconfigured.
Frequently asked questions
What is JWE in simple terms?
JWE is a standard way to encrypt a token so outsiders who intercept it cannot read the claims. Only parties with the right decryption key can recover the contents.
Is a normal JWT encrypted?
No. A typical signed JWT (JWS) is readable by anyone who has the string. Encryption requires JWE (or another confidentiality layer such as TLS alone for transit).
Does JWE replace signature verification?
Not by itself. Encryption protects secrecy. Authenticated encryption and/or nested signed JWTs still matter so recipients know who created the content and that it was not swapped.
What are the five parts of compact JWE?
Protected header, encrypted key, initialization vector, ciphertext, and authentication tag—five base64url segments separated by dots.
When should teams use JWE?
When tokens must cross untrusted intermediaries and claims include sensitive attributes that should not be visible to bearers or logs, or when regulations require claim confidentiality at rest in clients.
Is TLS enough without JWE?
TLS protects data in transit between two hops. It does not hide claims from the client holding the token, from browser storage, or from systems that log bearer tokens.
What is a content encryption key (CEK)?
A CEK is a symmetric key used to encrypt the payload. JWE often encrypts that CEK for each recipient using their key encryption algorithm.
References
Explore authoritative guidance and frameworks related to json web encryption (jwe).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.