...

JOSE is a set of high quality specifications that specify how data payloads can be signed/validated and/or encrypted/decrypted with the cryptographic properties set in the JSON-formatted metadata (headers). The data to be secured can be in JSON or other format formats (plain text, XML, binary data).

JOSE is a key piece of the advanced OAuth2 -based applications such as OpenIdConnect and OpenId Connect applications but can also be successfully used for securing the regular HTTP web service communications.

CXF 3.1.x and 3.2.0 provides provide a complete implementation of JOSE and offer a comprehensive utility and filter support for protecting JAX-RS services and clients with the help of JOSE.

CXF OAuth2 and OIDC modules are also depending on it.

Maven Dependencies

Having the following dependency will let the developers write JOSE JWS or JWE code: creating and securing JSON Web Tokens (JWT), and securing the arbitrary data (not only JSON)

<dependency>
  <groupId>org.apache.cxf</groupId>
  <artifactId>cxf-rt-rs-security-jose</artifactId>
  <version>3.1.7</version>
</dependency>

...

Having the following dependency will let the developers use JAX-RS JOSE filters which will transparently sign and/or encrypt the data streams, and decrypt or/and validate the incoming JOSE sequences and make the original data available for the processing.

...

Java7 or higher is recommended for in most cases: Java6 does not support JWE AES-GCM at all while with BouncyCastle it is not possible to submit JWE Header properties as an extra input to the encryption process to get them integrity protected which is not JWE compliant.

Unlimited JCE Policy for Java 7/8/9 needs to be installed if a size of the encrypting encryption key is 256 bits (example, JWE A256GCM).

...

Additionally, JWT (JSON Web Token), while technically being not part of JOSE, is often used as an input material to JWS and JWE processors, especially in OAuth2 flows (example: OAuth2 access tokens can be represented internally as JWT, OpenIdConnect IdToken and UserInfo are effectively JWTs). JWT describes how a set of claims in JSON format can be either JWS-signed and/or JWE-enctypted. 

...

The algorithms are split into 3 categories: signature algorithms (HMAC, RSA, Elliptic Curve), algorithms for supporting the encryption of content encryption keys (RSA-OAEP, AES Key Wrap, etc), and algorithms for encrypting the actual content (AES GCM , etcor AES CBC HMAC).

...

All JWS and JWE algorithms process not only the actual data but also the meta-data (the algorithm properties) thus ensuring the algorithm properties they are integrity-protected, additionally JWE algorithms produce authentication tags which ensure the already encrypted content won't be manipulated.

...

A collection of JWK keys is called a JWK Key Set which is represented as JSON array of JWKs.

JWK can contain X509 certificates or their thumbprints if preferred.

CXF offers a utility support for reading and writing JWK keys and key sets and for working with the encrypted inlined and standalone JWK stores in this package.

...

One can inline the encrypted key or the key set directly in the configuration properties. For example, here is how an encrypted single JWK key is inlined. Similarly, here is how an encrypted collection of keys is inlined.

CXF assumes that the JWK keys have been encrypted if a password provider is available in scopea request context, it is typically registered with JAX-RS endpoints. The encryption is done with a password based PBES2 algorithm. 

...

JOSE is already widely supported in OAuth2 and OIDC applications. Besides that CXF JOSE client or server will interoperate with a 3rd party client/server able to produce or consume JWS/JWE sequences.  For example, see the following a WebCrypto API use case, and  the following demo which demonstrates how a JWS sequence produced by a browser-hosted script can be validated by a server application capable of processing JWS, with the demo browser client being tested against a CXF JWS server too. 

...