When warehouse and payment services exchange refund data, signing detects tampering but leaves the contents readable. JSON Web Encryption (JWE) protects both confidentiality and integrity in a standardized JSON-based format. section 11.5 section 11.8
JWE represents encrypted content using JSON-based data structures. It can carry an arbitrary sequence of bytes, including text or structured JSON, and supports interoperability between applications written in different languages. section 11.5 section 11.0
A JWE object contains four functional parts:
- Header: identifies encryption algorithms and other processing metadata. section 11.5.1
- Encrypted key: optionally carries the content encryption key (CEK), unless the parties use a preagreed derivation or direct-encryption method. section 11.5.1
- Ciphertext: contains the encrypted payload, such as JSON data. section 11.5.1
- Authentication tag: detects changes to the encrypted data. section 11.5.1
Compact JWE serializes these parts as Base64-encoded segments separated by periods, making the value suitable for HTTP headers and URL query parameters. Direct encryption can omit the encrypted-key segment when both parties already share the content-encryption key. section 11.5.1 section 11.7
Encrypting and decrypting with Nimbus
A Java service can build a JWE with Nimbus by selecting JWEAlgorithm.DIR and EncryptionMethod.A256GCM, wrapping the payload in a JWEObject, encrypting it with DirectEncrypter, and serializing it. The receiving service parses the compact string, decrypts it with DirectDecrypter, and reads the payload. Nimbus handles initialization-vector generation, AES-GCM configuration, serialization, and parsing rather than requiring direct javax.crypto code. section 11.5.2
JWE belongs to the JOSE family: JWA names algorithms, JWK represents keys, JWS protects content from tampering without confidentiality, and JWE adds encryption. JWT is a related token format whose payload must be a JSON object; JWE payloads need not be JSON. section 11.1 section 11.6
Treat algorithm and key configuration as security decisions rather than defaults. JOSE’s flexibility can enable misuse, so use organization-approved configurations and make educational examples production-ready before deployment. section 11.6 section 11.8
Figure 11.1 Relationships between the standards that are part of the JOSE suite. JOSE enables interoperability between applications that want to exchange encrypted or signed data using the JSON data format. JOSE standards are used extensively by popular security protocols such as OIDC for single sign-on.
Use the JOSE relationship diagram to distinguish JWE from JWS, JWK, JWA, and JWT, and to see how these standards support interoperable JSON security protocols. section 11.1
