JWE

JWE (JSON Web Encryption, RFC 7516) is the encryption framework in the JOSE (JSON Object Signing and Encryption) family, sibling to JWS. Where JWS signs a payload (keeping it readable but tamper-evident), JWE encrypts the payload (keeping its contents confidential).

A JWE compact-serialisation token has five dot-separated segments instead of JWT’s three:

1. Header — JSON declaring the encryption algorithms.
2. Encrypted Content Encryption Key (CEK) — the symmetric key used for the payload, itself encrypted with the recipient’s key.
3. Initialization Vector (IV) — random per-encryption nonce.
4. Ciphertext — the actual encrypted payload.
5. Authentication tag — for AEAD modes; verifies the ciphertext hasn’t been tampered with.

JWE uses a hybrid scheme: a symmetric key (the CEK) encrypts the payload (because symmetric crypto is fast), then an asymmetric key encrypts the CEK (because asymmetric is the only way to keep keys exchangeable without a shared secret). Standard algorithms: RSA-OAEP for key wrap, A256GCM for payload encryption.

When to use JWE vs JWT: most authentication systems use JWT (signed but not encrypted) because the claims aren’t secret — a token containing “sub: user_123, exp: ...” is fine to read. Use JWE when the token contains genuinely sensitive payload (medical records, financial details, internal-only routing data) and you can’t guarantee that intermediaries won’t inspect it. Most modern systems prefer keeping sensitive data on the server and using a short opaque session ID instead — simpler than JWE.

Worked example

A token issuer needs to send a medical-record reference to a downstream service via the browser, but the browser must not be able to read it. The issuer creates a JWE: header {"alg":"RSA-OAEP-256","enc":"A256GCM","cty":"JWT","kid":"recipient-2026"}, payload {"patient_id":"P-12345","record_id":"R-78910"}. The issuer generates a random 256-bit CEK, encrypts the payload with AES-256-GCM under that key (producing ciphertext + 128-bit authentication tag), and encrypts the CEK itself under the recipient’s RSA public key. The output is five base64url-encoded segments joined by dots — about 600-800 bytes total. The recipient unwraps in reverse: RSA-decrypt the CEK using their private key, AES-GCM-decrypt the payload using the CEK, verify the auth tag matches. Any tampering with any of the five segments fails the auth-tag check and the recipient rejects the token. The browser carrying the JWE in between sees only opaque base64 — the patient/record IDs are inaccessible.

When and why it matters

JWE matters whenever a token has to traverse untrusted intermediaries while carrying confidential claims — patient data, financial routing details, internal user identifiers — and the architecture has to use a token rather than a server-side session. The mistake to avoid is reaching for JWE first when a simpler architecture works: most authentication flows are better served by signed JWTs containing only references (a user ID, a session ID) that intermediaries can see harmlessly, while the sensitive data stays in the issuer’s database. Use JWE when intermediaries are operationally required to hold the token but contractually or legally restricted from reading it — federated SSO across organisations, healthcare data exchange between providers, some open-banking PSD2 flows. The second mistake is mismatched algorithm choice: RSA-OAEP with SHA-1 is deprecated, RSA-OAEP-256 is the current recommendation; A128CBC-HS256 is still acceptable but A256GCM is preferred for new deployments. Reference: RFC 7518 — JSON Web Algorithms.

Nested JOSE — signing then encrypting: for tokens that need both authenticity (provable origin) and confidentiality, the standard pattern is signed-then-encrypted: the payload is first wrapped in a JWS, then the entire JWS becomes the payload of a JWE. The header field cty: "JWT" in the outer JWE signals to the parser that the decrypted contents are themselves a JOSE token to be verified. The reverse ordering (encrypt then sign) is less secure because the signature would be over ciphertext that could be replayed across recipients. Most enterprise SSO platforms that use JWE (Microsoft Azure AD federation tokens, some banking APIs) ship signed-then-encrypted as standard. Reference: RFC 7516 — JSON Web Encryption.