...

Once you have decided which algorithm needs to be supported you can initialize an appropriate pair of JwsSignatureProvider and JwsSignatureVerifier if both signing the data and the verification are needed. If only the signing is needed - select JwsSignatureProvider, only the verification - select JwsSignatureVerifier. The selected providers are submitted directly or indirectly to JWS Compact or JWS JSON producers or consumers.

JwsUtils utility class has a lot of helper methods to load JwsSignatureProvider or JwsSignatureVerifier and to get JWS sequences created and validated.

JWS Compact

JWS Compact representation is the most often used JOSE JWS sequence format. It is the concatenation of Base64URL-encoded sequence if of JWS headers (algorithm and other properties),  Base64URL-encoded sequence of the actual data being protected and Base64URL-encoded sequence of the signature algorithm output bytes.

...

In this latest example a plain text sequence is encoded with a private RSA key loaded from the JWK store and validated with a public RSA key loaded from the existing Java JKS store.

JwsUtils utility class has a lot of helper methods to get JWS sequences created and validated.

JWS JSON

While JWS Compact is optimized and represents a concatenation of up to 3 Base64URL values, JWS JSON is an open JSON container, see Appendix 6.

...

All of the above providers can be initialized with the keys loaded from JWK or Java JKS stores or from the in-memory representations.

JWE Compact

Once you have decided which key and content encryption algorithms need to be supported you can initialize JwsEncryptionProvider and JwsDecryptionProvider which do the actual JWE encryption/decryption work by coordinating with the key and content encryption providers. CXF ships JweEncryption (JwsEncryptionProvider) and JweDecryption (JweDecryptionProvider) helpers, simply pass them the preferred key and content encryption providers and have the content encrypted or decrypted.

Note that AesCbcHmacJweEncryption and AesCbcHmacJweDecryption providers supporting AES_CBC_HMAC_SHA2 contet encryption are extending JweEncryption and JweDecryption respectively. They implement the content encryption internally but do accept preferred key encryption/decryption providers.

Similarly, DirectKeyJweEncryption and DirectKeyJweDecryption are simple JweEncryption and JweDecryption extensions making it straighforward to do the direct key content encryption/decryption.

JweUtils utility class has a lot of helper methods to load key and and content encryption providers and get the data encrypted and decrypted.

JWE Compact

JWE Compact representation is the most often used JWE sequence format. It is the concatenation of 5 parts: Base64URL-encoded sequence of JWE headers (algorithm and other properties),  Base64URL-encoded sequence of JWE encryption key (empty in case of the direct encryption), Base64URL-encoded sequence of JWE Initialization vector, Base64URL-encoded sequence of the produced ciphertext (encrypted data) and finally Base64URL-encoded sequence of the authentication tag (integrity protection for the headers and the ciphertext itself).

JweCompactProducer and JweCompactConsumer offer a basic support for creating and consuming compact JWE sequences. In most cases you will likely prefer to use JweEncryption (uses JweCompactProducer internally) and JweDecryption (uses JweCompactConsumer internally).

JweJwtCompactProducer and JwsJwtCompactConsumer help with directly encrypting typed JWT TokensJweEncryptionProvider supports encrypting the content, JweDecryptionProvider - decrypting the content. Encryptors and Decryptors for all of JWE algorithms are shipped.

Here is the example of doing AES CBC HMAC and AES Key Wrap in CXF:

...

OIDC heavily depends on JOSE. CXF OIDC module utilizes a JOSE module to support OIDC RP and IDP code. Add more...

Future Work

OAuth2, WebCrypto, OIDC, etc

Third-Party Alternatives

Jose4J

...