...

JwsJsonProducer producer = new JwsJsonProducer(UNSIGNED_PLAIN_JSON_DOCUMENT);
JwsHeaders headerEntries = new JwsHeaders(SignatureAlgorithm.HS256);
              
producer.signWith(new HmacJwsSignatureProvider(ENCODED_MAC_KEY_1, SignatureAlgorithm.HS256),
                  headerEntries);
producer.signWith(new HmacJwsSignatureProvider(ENCODED_MAC_KEY_2, SignatureAlgorithm.HS256),
                  headerEntries);
assertEquals(DUAL_SIGNED_JWS_JSON_DOCUMENT, producer.getJwsJsonSignedDocument());

JwsJsonConsumer consumer = new JwsJsonConsumer(DUAL_SIGNED_DOCUMENT); 

// Validate both signatures, see below how to validate and produce
JsonWebKeys jwks = readKeySet("jwkSet.txt");
        
List<JwsJsonSignatureEntry> sigEntries = consumer.getSignatureEntries();
assertEquals(2, sigEntries.size());

// 1st signature
String firstKid = (String)sigEntries.get(0).getKeyId();
JsonWebKey firstKey = jwks.getKey(firstKid);
assertTrue(sigEntries.get(0).verifySignatureWith(firstKey));
// 2nd signature
String secondKid = (String)sigEntries.get(1).getKeyId();
JsonWebKey secondKey = jwks.getKey(secondKid);
assertTrue(sigEntries.get(1).verifySignatureWith(secondKey));

// or if you wish to validate (ex with the firstKey loaded above) and forward it to the next consumer, do:
JwsSignatureProvider provider = JwsUtils.getSignatureProvider(firstKey);
String nextJwsJson = consumer.validateAndProduce(Collections.singletonList(provider));
// use WebClient to post nextJwsJson to the next consumer, with nextJwsJson being nearly identical to the original
// double-signed JWS JSON signature, minus the signature which was already validated, in this case nextJwsJson will 
// only have a single signature 

Does it make sense to use JWS JSON if you do not plan to do multiple signatures ? Indeed, if it is only a single signature then using JWS Compact is a good alternative, likely to be used most often.

The above code produces a JWS JSON sequence containing two signatures, similarly to this example. If the sequence contains a single signature only then the JWS JSON 'signatures' array will contain a single 'signature' element, or the whole sequence can be flattened with the actual 'signatures' array dropped. JwsJsonProducer  does not produce the flattened sequence when only a single signature is used by default because 3rd party JWS JSON consumers may only be able to process the sequences with the 'signatures' array, so pass a 'supportFlattened' flag to JwsJsonProducer if needed. 

Does it make sense to use JWS JSON if you do not plan to do multiple signatures ? Indeed, if it is only a single signature then using JWS Compact is a good alternative, likely to be used most often.

However, even if you do a single signature, you may still want to try JWS JSON because is is easier to observe the individual JWS JSON However, even if you do a single signature, you may still want to try JWS JSON because is is easier to observe the individual JWS JSON structure parts when, example, checking the logs or TCP-tracing HTTP requests/responses. This is especially true when we start talking about a clear an unencoded payload option, see below.

...

For example, if the producer and consumer can both access the same shared piece of data, then the producer can sign these data, post the JWS sequence (without the data) to the consumer. The consumer will validate this JWS sequence and assert the data have not been modified by the time it has received and started validating the sequence. You fill find JWS Compact and JWS JSON Producer and Consumer providers accepting provider constructors accept an optional 'detached' flag in cases were it is required.      

JWS with

...

Unencoded Payload

JWE Encryption

JWE (JSON Web Encryption) document describes how a document content, and, when applicable, a content encryption key, can be encrypted. For example, Appendix A1 shows how the content can be encrypted with a secret key using AesGcm with the actual content encryption key being encrypted using RSA-OAEP.

CXF ships JWE related classes in this package and offers a support for all of JWA key encryption and content encryption algorithms.

Key and Content Encryption Providers

JWE Encryption process typically involves a content-encryption key being generated with this key being subsequently encrypted/wrapped with a key known to the consumer. Thus CXF offers the providers for supporting the key-encryption algorithms and providers for supporting the content-encryption algorithms. Direct key encryption (where the content-encryption key is established out of band) is also supported.

By default, JWS Compact and JWS JSON sequences have the data first Base64Url encoded and then inlined in the resulting sequence. This is useful especially for JWS Compact which is used in OAuth2/OIDC  flows to represent the signed access or id tokens. 

One concern around the data being inlined is that it takes an extra time to Base64Url encode them which may become noticeable with large payloads, and another one is that one can not see the data while looking at JWS sequences in the logs or trace screens.

Thus a JWS with Unencoded Payload option (JWS header 'b64' property set to false) has been introduced to let users configure JWS Signature providers not to encode the actual data payload. As it happens it appears to be most useful when JWS JSON sequences are produced, see this example.

Note that JWS Compact also supports 'b64' property but only with the detached payloads. It is easier to appreciate the value of disabling Base64Url encoding with JWS JSON as seen in the example.

In CXF you can apply this option to both JWS Compact and JWS JSON sequences, here is a JWS JSON code fragment:

JwsJsonProducer producer = new JwsJsonProducer(UNSIGNED_PLAIN_JSON_DOCUMENT, true);
JwsHeaders headers = new JwsHeaders(SignatureAlgorithm.HS256);
headers.setPayloadEncodingStatus(false);
producer.signWith(new HmacJwsSignatureProvider(ENCODED_MAC_KEY_1, SignatureAlgorithm.HS256),
                  headers);

JWE Encryption

JWE (JSON Web Encryption) document describes how a document content, and, when applicable, a content encryption key, can be encrypted. For example, Appendix A1 shows how the content can be encrypted with a secret key using AesGcm with the actual content encryption key being encrypted using RSA-OAEP.

CXF ships JWE related classes in this package and offers a support for all of JWA key encryption and content encryption algorithms.

Key and Content Encryption Providers

JWE Encryption process typically involves a content-encryption key being generated with this key being subsequently encrypted/wrapped with a key known to the consumer. Thus CXF offers the providers for supporting the key-encryption algorithms and providers for supporting the content-encryption algorithms. Direct key encryption (where the content-encryption key is established out of band) is also supported.

KeyEncryptionProvider supports encrypting a content-encryption key, KeyDecryptionProvider - decrypting it.

...

Configuration that applies to JWT tokens only

Configuration that applies to JWT tokens only

OAuth2 and Jose

CXF OAuth2 module depends on its JOSE module. This will be used to support OAuth2 POP tokens. Authorization code JOSE requests can already be processed. Utility support for validating JWT-based access tokens is provided.

Add more...

OIDC and Jose

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 is a top project from Brian Campbell.  CXF users are encouraged to experiment with Jose4J (or indeed with other 3rd party implementations) if they prefer.

TODO: describe how Jose4J can be integrated with CXF filters if preferred.

...

OAuth2 and Jose

CXF OAuth2 module depends on its JOSE module. This will be used to support OAuth2 POP tokens. Authorization code JOSE requests can already be processed. Utility support for validating JWT-based access tokens is provided.

Add more...

OIDC and Jose

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 is a top project from Brian Campbell.  CXF users are encouraged to experiment with Jose4J (or indeed with other 3rd party implementations) if they prefer.

TODO: describe how Jose4J can be integrated with CXF filters if preferred.