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.