You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cxf.apache.org by bu...@apache.org on 2016/05/26 10:47:42 UTC
svn commit: r989178 - in /websites/production/cxf/content:
cache/docs.pageCache docs/jax-rs-jose.html docs/jax-rs-oauth2.html
Author: buildbot
Date: Thu May 26 10:47:42 2016
New Revision: 989178
Log:
Production update by buildbot for cxf
Modified:
websites/production/cxf/content/cache/docs.pageCache
websites/production/cxf/content/docs/jax-rs-jose.html
websites/production/cxf/content/docs/jax-rs-oauth2.html
Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/cxf/content/docs/jax-rs-jose.html
==============================================================================
--- websites/production/cxf/content/docs/jax-rs-jose.html (original)
+++ websites/production/cxf/content/docs/jax-rs-jose.html Thu May 26 10:47:42 2016
@@ -119,11 +119,11 @@ Apache CXF -- JAX-RS JOSE
<!-- Content -->
<div class="wiki-content">
<div id="ConfluenceContent"><p> </p><p> </p><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1464256020773 {padding: 0px;}
-div.rbtoc1464256020773 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1464256020773 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1464259621584 {padding: 0px;}
+div.rbtoc1464259621584 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1464259621584 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1464256020773">
+/*]]>*/</style></p><div class="toc-macro rbtoc1464259621584">
<ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSJOSE-Introduction">Introduction</a></li><li><a shape="rect" href="#JAX-RSJOSE-MavenDependencies">Maven Dependencies</a></li><li><a shape="rect" href="#JAX-RSJOSE-JavaandJCEPolicy">Java and JCE Policy </a></li><li><a shape="rect" href="#JAX-RSJOSE-JOSEOverviewandImplementation">JOSE Overview and Implementation</a>
<ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSJOSE-JWAAlgorithms">JWA Algorithms</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWKKeys">JWK Keys</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWSSignature">JWS Signature</a>
<ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSJOSE-SignatureandVerificationProviders">Signature and Verification Providers</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWSCompact">JWS Compact</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWSJSON">JWS JSON</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWSwithDetachedContent">JWS with Detached Content</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWSwithUnencodedPayload">JWS with Unencoded Payload</a></li></ul>
@@ -169,7 +169,7 @@ private static void registerBouncyCastle
private static void unregisterBouncyCastle() throws Exception {
Security.removeProvider(BouncyCastleProvider.PROVIDER_NAME);
}</pre>
-</div></div><p> </p><h1 id="JAX-RSJOSE-JavaandJCEPolicy">Java and JCE Policy </h1><p>Java7 or higher is recommended in most cases.</p><p>JWE:</p><p>Java6 does not support JWE AES GCM key wrap and content encryption algorithms (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), however with Java 6 one can use AesCbcHmac content encryption if BouncyCastle is installed.</p><p>Unlimited JCE Policy for Java 7/8/9 needs to be installed if a size of the encryption key is 256 bits (example, JWE A256GCM).</p><p>JWS:</p><p>Java 6 should also be fine but note only CXF 3.0.x can be run with Java 6.</p><h1 id="JAX-RSJOSE-JOSEOverviewandImplementation">JOSE Overview and Implementation</h1><p>JOSE consists of the following key parts:</p><ul><li><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518" rel="nofollow">JWA</a> - JSON Web Algorithms where all supported
signature and encryption algorithms are listed</li><li><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7517" rel="nofollow">JWK</a> - JSON Web Keys - introduces a JSON format for describing the public and private keys used by JWA algorithms</li><li><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7515" rel="nofollow">JWS</a> - JSON Web Signature - describes how the data can be signed or validated and introduces compact and JSON JWS formats for representing the signed data</li><li><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7516" rel="nofollow">JWE</a> - JSON Web Encryption - describes how the data can be encrypted or decrypted and introduces compact and JSON JWE formats for representing the encrypted data  </li></ul><p>Additionally, <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7519" rel="nofollow">JWT</a> (JSON Web Token), while technically being not part of J
OSE, 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). <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7519" rel="nofollow">JWT</a> describes how a set of claims in JSON format can be JWS-signed and/or JWE-enctypted. </p><h2 id="JAX-RSJOSE-JWAAlgorithms">JWA Algorithms</h2><p>All JOSE signature and encryption algorithms are grouped and described in the <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518" rel="nofollow">JWA</a> (JSON Web Algorithms) specification.</p><p>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 or AES CBC HMAC).</p><div>The specification li
sts all the algorithms that can be used for signing or encrypting the data and also describes how some of these algorithms work in cases</div><div>where Java JCA (or BouncyCastle) does not support them directly, example, AES-CBC-HMAC-SHA2.</div><div>Algorithm name is a type + hint, example: HS256 (HMAC with SHA-256), RSA-OAEP-256 (RSA OAEP key encryption with SHA-256), etc.</div><p>All JWS and JWE algorithms process not only the actual data but also the meta-data (the algorithm properties) thus ensuring they are integrity-protected, additionally JWE algorithms produce authentication tags which ensure the already encrypted content won't be manipulated.</p><p>Please refer to <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518" rel="nofollow">the specification</a> to get all the information needed (with the follow up links to the corresponding RFC when applicable) about a particular signature or encryption algorithm: the properties, recommended key sizes, ot
her security considerations related to all of or some specific algorithms. CXF JOSE code already enforces a number of the recommended constraints.</p><p>CXF offers the utility support for working with JWA algorithms in <a shape="rect" class="external-link" href="https://github.com/apache/cxf/tree/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwa" rel="nofollow">this package</a>.</p><p>Typically one would supply an algorithm property in a type-safe way either to JWS or JWE processor, for example,  SignatureAlgorithm.HS256 for JWS, KeyAlgorithm.A256KW plus ContentAlgorithm.A256GCM for JWE, etc. Each enum has methods for checking a key size, JWA and Java JCA algorithm names.</p><h2 id="JAX-RSJOSE-JWKKeys">JWK Keys</h2><p><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7517" rel="nofollow">JWK</a> (JSON Web Key) is a JSON document describing the cryptographic key properties. JWKs are very flexible and one can ex
pect JWKs becoming one of the major mechanisms for representing and storing cryptographic keys. While one does not have to represent the keys as JWK in order to sign or encrypt the document and rely on Java JCA secret and asymmetric keys instead, JWK is a preferred representation of signature or encryption keys in JOSE.</p><p>For example:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Secret HMAC Key</b></div><div class="codeContent panelContent pdl">
+</div></div><p> </p><h1 id="JAX-RSJOSE-JavaandJCEPolicy">Java and JCE Policy </h1><p>Java7 or higher is recommended in most cases.</p><p><strong>JWE</strong></p><p>Java6 does not support JWE AES GCM key wrap and content encryption algorithms (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), however with Java 6 one can use AesCbcHmac content encryption if BouncyCastle is installed.</p><p>Unlimited JCE Policy for Java 7/8/9 needs to be installed if a size of the encryption key is 256 bits (example, JWE A256GCM).</p><p><strong>JWS</strong></p><p>Java 6 should also be fine but note only CXF 3.0.x can be run with Java 6.</p><h1 id="JAX-RSJOSE-JOSEOverviewandImplementation">JOSE Overview and Implementation</h1><p>JOSE consists of the following key parts:</p><ul><li><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518" rel="nofollow">JWA</a> - JSON We
b Algorithms where all supported signature and encryption algorithms are listed</li><li><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7517" rel="nofollow">JWK</a> - JSON Web Keys - introduces a JSON format for describing the public and private keys used by JWA algorithms</li><li><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7515" rel="nofollow">JWS</a> - JSON Web Signature - describes how the data can be signed or validated and introduces compact and JSON JWS formats for representing the signed data</li><li><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7516" rel="nofollow">JWE</a> - JSON Web Encryption - describes how the data can be encrypted or decrypted and introduces compact and JSON JWE formats for representing the encrypted data  </li></ul><p>Additionally, <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7519" rel="nofollow">JWT</a> (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). <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7519" rel="nofollow">JWT</a> describes how a set of claims in JSON format can be JWS-signed and/or JWE-enctypted. </p><h2 id="JAX-RSJOSE-JWAAlgorithms">JWA Algorithms</h2><p>All JOSE signature and encryption algorithms are grouped and described in the <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518" rel="nofollow">JWA</a> (JSON Web Algorithms) specification.</p><p>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 or AES CBC HMA
C).</p><div>The specification lists all the algorithms that can be used for signing or encrypting the data and also describes how some of these algorithms work in cases</div><div>where Java JCA (or BouncyCastle) does not support them directly, example, AES-CBC-HMAC-SHA2.</div><div>Algorithm name is a type + hint, example: HS256 (HMAC with SHA-256), RSA-OAEP-256 (RSA OAEP key encryption with SHA-256), etc.</div><p>All JWS and JWE algorithms process not only the actual data but also the meta-data (the algorithm properties) thus ensuring they are integrity-protected, additionally JWE algorithms produce authentication tags which ensure the already encrypted content won't be manipulated.</p><p>Please refer to <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518" rel="nofollow">the specification</a> to get all the information needed (with the follow up links to the corresponding RFC when applicable) about a particular signature or encryption algorithm: the prope
rties, recommended key sizes, other security considerations related to all of or some specific algorithms. CXF JOSE code already enforces a number of the recommended constraints.</p><p>CXF offers the utility support for working with JWA algorithms in <a shape="rect" class="external-link" href="https://github.com/apache/cxf/tree/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwa" rel="nofollow">this package</a>.</p><p>Typically one would supply an algorithm property in a type-safe way either to JWS or JWE processor, for example,  SignatureAlgorithm.HS256 for JWS, KeyAlgorithm.A256KW plus ContentAlgorithm.A256GCM for JWE, etc. Each enum has methods for checking a key size, JWA and Java JCA algorithm names.</p><h2 id="JAX-RSJOSE-JWKKeys">JWK Keys</h2><p><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7517" rel="nofollow">JWK</a> (JSON Web Key) is a JSON document describing the cryptographic key properties. JWKs
are very flexible and one can expect JWKs becoming one of the major mechanisms for representing and storing cryptographic keys. While one does not have to represent the keys as JWK in order to sign or encrypt the document and rely on Java JCA secret and asymmetric keys instead, JWK is a preferred representation of signature or encryption keys in JOSE.</p><p>For example:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>Secret HMAC Key</b></div><div class="codeContent panelContent pdl">
<pre class="brush: js; gutter: false; theme: Default" style="font-size:12px;">{
"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow",
@@ -277,7 +277,7 @@ JwsHeaders headers = new JwsHeaders(Sign
headers.setPayloadEncodingStatus(false);
producer.signWith(new HmacJwsSignatureProvider(ENCODED_MAC_KEY_1, SignatureAlgorithm.HS256),
headers);</pre>
-</div></div><p>Note that JWS Compact uses a '.' as a separator between its 3 parts. <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7797#section-5" rel="nofollow">JWS with Unencoded Payload</a> recommends that it is the application's responsibility to deal with the unencoded payloads which may have '.' characters. Similarly, JWS JSON unencoded payloads with double quotes will need to be taken care of by the application. </p><h2 id="JAX-RSJOSE-JWEEncryption">JWE Encryption</h2><p><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7516" rel="nofollow">JWE</a> (JSON Web Encryption) document describes how a document content, and, when applicable, a content encryption key, can be encrypted. For example, <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7516#appendix-A.1" rel="nofollow">Appendix A1</a> shows how the content can be encrypted with a secret key using AesGcm with the actual content encryption key
being encrypted using RSA-OAEP.</p><p>CXF ships JWE related classes in <a shape="rect" class="external-link" href="https://github.com/apache/cxf/tree/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe" rel="nofollow">this package</a> and offers a support for all of JWA <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4" rel="nofollow">key encryption</a> and <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-5" rel="nofollow">content encryption</a> algorithms.</p><h3 id="JAX-RSJOSE-KeyandContentEncryptionProviders">Key and Content Encryption Providers</h3><p>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.</p><p><a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/KeyEncryptionProvider.java" rel="nofollow">KeyEncryptionProvider</a> supports encrypting a content-encryption key, <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/KeyDecryptionProvider.java" rel="nofollow">KeyDecryptionProvider</a> - decrypting it.</p><p>The following table shows the key encryption algorithms and the corresponding providers (<span class="pl-smi">org.apache.cxf.rs.security.jose.jwe</span> package):</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1" class="confluenceTd"><strong>Algorithm</strong></td><td colspan="1" rowspan="1" class="confluenc
eTd"><strong>JWE Header 'alg'</strong></td><td colspan="1" rowspan="1" class="confluenceTd"><strong>KeyEncryptionProvider</strong></td><td colspan="1" rowspan="1" class="confluenceTd"><strong>KeyDecryptionProvider</strong></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.2" rel="nofollow">RSAES-PKCS1-v1_5</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">RSA1_5</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>RSAKeyEncryptionAlgorithm</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>RSAKeyDecryptionAlgorithm</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.3" rel="nofollow">RSAES OAEP</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">RSA-OAEP, RSA-OAEP-256</p></td><td colspan="1" rowspan="1" class="confl
uenceTd">RSAKeyEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">RSAKeyDecryptionAlgorithm</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.4" rel="nofollow">AES Key Wrap</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">A128KW, A192KW, A256KW</p></td><td colspan="1" rowspan="1" class="confluenceTd">AesKeyWrapEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">AesKeyWrapDecryptionAlgorithm</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.5" rel="nofollow">Direct</a></td><td colspan="1" rowspan="1" class="confluenceTd">dir</td><td colspan="1" rowspan="1" class="confluenceTd">DirectKeyEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">DirectKeyDecryptionAlgorithm</td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#page-15" rel="nofollow">ECDH-ES Wrap</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">ECDH-ES+A128KW (+A192KW, +256KW)</p></td><td colspan="1" rowspan="1" class="confluenceTd">EcdhAesWrapKeyEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">EcdhAesWrapKeyDecryptionAlgorithm</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#page-15" rel="nofollow">ECDH-ES Direct</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">ECDH-ES</p></td><td colspan="1" rowspan="1" class="confluenceTd"><span class="pl-en">EcdhDirectKeyJweEncryption</span></td><td colspan="1" rowspan="1" class="confluenceTd"><span class="pl-en">EcdhDirectKeyJweDecryption</span></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect"
class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.7" rel="nofollow">AES-GCM</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">A128GCMKW, A192GCMKW, A256GCMKW</p></td><td colspan="1" rowspan="1" class="confluenceTd">AesGcmWrapKeyEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">AesGcmWrapKeyDecryptionAlgorithm</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.8" rel="nofollow">PBES2</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">PBES2-HS256+A128KW</p><p class="newpage">PBES2-HS384+A192KW</p><p class="newpage">PBES2-HS512+A256KW</p></td><td colspan="1" rowspan="1" class="confluenceTd">PbesHmacAesWrapKeyEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">PbesHmacAesWrapKeyDecryptionAlgorithm</td></tr></tbody></table></div><p> </p><p>RSA-OAEP algorithms are li
kely to be used most often at the moment due to existing JKS stores being available everywhere and a relatively easy way of making the public validation keys available.</p><p><a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/ContentEncryptionProvider.java" rel="nofollow">ContentEncryptionProvider</a> supports encrypting a generated content-encryption key, <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/ContentDecryptionProvider.java" rel="nofollow">ContentDecryptionProvider</a> - decrypting it.</p><p>The following table shows the content encryption algorithms and the corresponding providers:</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1" class="confluenceTd"><strong>Algorithm</strong></td><td colspan
="1" rowspan="1" class="confluenceTd"><strong>JWE Header 'enc'</strong></td><td colspan="1" rowspan="1" class="confluenceTd"><strong>ContentEncryptionProvider</strong></td><td colspan="1" rowspan="1" class="confluenceTd"><strong>ContentDecryptionProvider</strong></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-5.2" rel="nofollow">AES_CBC_HMAC_SHA2</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">A128CBC-HS256(-HS384, -HS512)</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>AesCbcHmacJweEncryption,</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>AesCbcHmacJweDecryption</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-5.3" rel="nofollow">AES-GCM</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">A128GCM, A92
GCM, A256GCM</p></td><td colspan="1" rowspan="1" class="confluenceTd">AesGcmContentEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">AesGcmContentDecryptionAlgorithm</td></tr></tbody></table></div><p>All of the above providers can be initialized with the keys loaded from JWK or Java JKS stores or from the in-memory representations.</p><p>Once you have decided which key and content encryption algorithms need to be supported you can initialize <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryptionProvider.java" rel="nofollow">JwsEncryptionProvider</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweDecryptionProvider.java" rel="nofollow">JwsDecryptionProvider</a> which do the actual JWE encryption/decryption work
by coordinating with the key and content encryption providers. CXF ships <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryption.java" rel="nofollow">JweEncryption</a> (JwsEncryptionProvider) and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweDecryption.java" rel="nofollow">JweDecryption</a> (JweDecryptionProvider) helpers, simply pass them the preferred key and content encryption providers and have the content encrypted or decrypted.</p><p>JweEncryption and JweDecryption help with creating and processing JWE Compact sequences (see the next section).  JweEncryption can also help with streaming JWE JSON sequences (see JAX-RS JWE filters section).</p><p>Note that <a shape="rect" class="external-link" href="https://github.com/apache/c
xf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/AesCbcHmacJweEncryption.java" rel="nofollow">AesCbcHmacJweEncryption</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/AesCbcHmacJweDecryption.java" rel="nofollow">AesCbcHmacJweDecryption</a> providers supporting <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-5.2" rel="nofollow">AES_CBC_HMAC_SHA2</a> contet encryption are extending JweEncryption and JweDecryption respectively. They implement <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-5.2.2" rel="nofollow">the content encryption</a> internally but do accept preferred key encryption/decryption providers.</p><p>Similarly, <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent
/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/DirectKeyJweEncryption.java" rel="nofollow">DirectKeyJweEncryption</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/DirectKeyJweDecryption.java" rel="nofollow">DirectKeyJweDecryption</a> are simple JweEncryption and JweDecryption extensions making it straighforward to do the direct key content encryption/decryption.</p><p><a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweUtils.java" rel="nofollow">JweUtils</a> utility class has a lot of helper methods to load key and and content encryption providers and get the data encrypted and decrypted.</p><h3 id="JAX-RSJOSE-JWECompact">JWE Compact</h3><p><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7516#section-
3.3" rel="nofollow">JWE Compact representation</a> 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).</p><p><a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweCompactProducer.java" rel="nofollow">JweCompactProducer</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweCompactConsu
mer.java" rel="nofollow">JweCompactConsumer</a> offer a basic support for creating and consuming compact JWE sequences. In most cases you will likely prefer to use <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryption.java" rel="nofollow">JweEncryption</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweDecryption.java" rel="nofollow">JweDecryption</a> instead: <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryption.java" rel="nofollow">JweEncryption</a> uses JweCompactProducer internally when its <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/
jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryptionProvider.java#L27" rel="nofollow">encrypt</a> method is called (<a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryptionProvider.java#L32" rel="nofollow">getEncryptedOutput</a> will be discussed in the JAX-RS JWE filters section), and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweDecryption.java" rel="nofollow">JweDecryption</a> accepts only JWE Compact and uses JweCompactConsumer internally.</p><p><a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweJwtCompactProducer.java" rel="nofollow">JweJwtCompactProducer</a> and <a shape="rect" class="external-link
" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jws/JwsJwtCompactConsumer.java" rel="nofollow">JwsJwtCompactConsumer</a> help with directly encrypting typed JWT Tokens.</p><p>Here is the example of doing AES Key Wrap and AES CBC HMAC in CXF:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>CXF Jwe AesWrapAesCbcHMac</b></div><div class="codeContent panelContent pdl">
+</div></div><p>Note that JWS Compact uses a '.' as a separator between its 3 parts. <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7797#section-5" rel="nofollow">JWS with Unencoded Payload</a> recommends that it is the application's responsibility to deal with the unencoded payloads which may have '.' characters. Similarly, JWS JSON unencoded payloads with double quotes will need to be taken care of by the application. </p><h2 id="JAX-RSJOSE-JWEEncryption">JWE Encryption</h2><p><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7516" rel="nofollow">JWE</a> (JSON Web Encryption) document describes how a document content, and, when applicable, a content encryption key, can be encrypted. For example, <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7516#appendix-A.1" rel="nofollow">Appendix A1</a> shows how the content can be encrypted with a secret key using AesGcm with the actual content encryption key
being encrypted using RSA-OAEP.</p><p>CXF ships JWE related classes in <a shape="rect" class="external-link" href="https://github.com/apache/cxf/tree/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe" rel="nofollow">this package</a> and offers a support for all of JWA <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4" rel="nofollow">key encryption</a> and <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-5" rel="nofollow">content encryption</a> algorithms.</p><h3 id="JAX-RSJOSE-KeyandContentEncryptionProviders">Key and Content Encryption Providers</h3><p>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.</p><p><a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/KeyEncryptionProvider.java" rel="nofollow">KeyEncryptionProvider</a> supports encrypting a content-encryption key, <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/KeyDecryptionProvider.java" rel="nofollow">KeyDecryptionProvider</a> - decrypting it.</p><p>The following table shows the key encryption algorithms and the corresponding providers (<span class="pl-smi">org.apache.cxf.rs.security.jose.jwe</span> package):</p><div class="table-wrap"><table class="confluenceTable"><tbody><tr><td colspan="1" rowspan="1" class="confluenceTd"><strong>Algorithm</strong></td><td colspan="1" rowspan="1" class="confluenc
eTd"><strong>JWE Header 'alg'</strong></td><td colspan="1" rowspan="1" class="confluenceTd"><strong>KeyEncryptionProvider</strong></td><td colspan="1" rowspan="1" class="confluenceTd"><strong>KeyDecryptionProvider</strong></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.2" rel="nofollow">RSAES-PKCS1-v1_5</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">RSA1_5</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>RSAKeyEncryptionAlgorithm</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>RSAKeyDecryptionAlgorithm</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.3" rel="nofollow">RSAES OAEP</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">RSA-OAEP, RSA-OAEP-256</p></td><td colspan="1" rowspan="1" class="confl
uenceTd">RSAKeyEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">RSAKeyDecryptionAlgorithm</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.4" rel="nofollow">AES Key Wrap</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">A128KW, A192KW, A256KW</p></td><td colspan="1" rowspan="1" class="confluenceTd">AesKeyWrapEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">AesKeyWrapDecryptionAlgorithm</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.5" rel="nofollow">Direct</a></td><td colspan="1" rowspan="1" class="confluenceTd">dir</td><td colspan="1" rowspan="1" class="confluenceTd">DirectKeyEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">DirectKeyDecryptionAlgorithm</td></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#page-15" rel="nofollow">ECDH-ES Key Wrap</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">ECDH-ES+A128KW (+A192KW, +256KW)</p></td><td colspan="1" rowspan="1" class="confluenceTd">EcdhAesWrapKeyEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">EcdhAesWrapKeyDecryptionAlgorithm</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#page-15" rel="nofollow">ECDH-ES Direct</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">ECDH-ES</p></td><td colspan="1" rowspan="1" class="confluenceTd"><span class="pl-en">EcdhDirectKeyJweEncryption</span></td><td colspan="1" rowspan="1" class="confluenceTd"><span class="pl-en">EcdhDirectKeyJweDecryption</span></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="r
ect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.7" rel="nofollow">AES-GCM Key Wrap</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">A128GCMKW, A192GCMKW, A256GCMKW</p></td><td colspan="1" rowspan="1" class="confluenceTd">AesGcmWrapKeyEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">AesGcmWrapKeyDecryptionAlgorithm</td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-4.8" rel="nofollow">PBES2</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">PBES2-HS256+A128KW</p><p class="newpage">PBES2-HS384+A192KW</p><p class="newpage">PBES2-HS512+A256KW</p></td><td colspan="1" rowspan="1" class="confluenceTd">PbesHmacAesWrapKeyEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">PbesHmacAesWrapKeyDecryptionAlgorithm</td></tr></tbody></table></div><p> </p><p>RSA-OAEP algo
rithms are likely to be used most often at the moment due to existing JKS stores being available everywhere and a relatively easy way of making the public validation keys available.</p><p>BouncyCastle is required if you use AES Key or AES-GCM Key Wrap or PBES2 key encryption.</p><p><a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/ContentEncryptionProvider.java" rel="nofollow">ContentEncryptionProvider</a> supports encrypting a generated content-encryption key, <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/ContentDecryptionProvider.java" rel="nofollow">ContentDecryptionProvider</a> - decrypting it.</p><p>The following table shows the content encryption algorithms and the corresponding providers:</p><div class="table-wrap"><table class="confluenceT
able"><tbody><tr><td colspan="1" rowspan="1" class="confluenceTd"><strong>Algorithm</strong></td><td colspan="1" rowspan="1" class="confluenceTd"><strong>JWE Header 'enc'</strong></td><td colspan="1" rowspan="1" class="confluenceTd"><strong>ContentEncryptionProvider</strong></td><td colspan="1" rowspan="1" class="confluenceTd"><strong>ContentDecryptionProvider</strong></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-5.2" rel="nofollow">AES_CBC_HMAC_SHA2</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">A128CBC-HS256(-HS384, -HS512)</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>AesCbcHmacJweEncryption,</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>AesCbcHmacJweDecryption</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-5.3" rel
="nofollow">AES-GCM</a></td><td colspan="1" rowspan="1" class="confluenceTd"><p class="newpage">A128GCM, A92GCM, A256GCM</p></td><td colspan="1" rowspan="1" class="confluenceTd">AesGcmContentEncryptionAlgorithm</td><td colspan="1" rowspan="1" class="confluenceTd">AesGcmContentDecryptionAlgorithm</td></tr></tbody></table></div><p>All of the above providers can be initialized with the keys loaded from JWK or Java JKS stores or from the in-memory representations.</p><p>BouncyCastle is required if you use AES_CBC_HMAC content encryption.</p><p>Once you have decided which key and content encryption algorithms need to be supported you can initialize <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryptionProvider.java" rel="nofollow">JwsEncryptionProvider</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jos
e-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweDecryptionProvider.java" rel="nofollow">JwsDecryptionProvider</a> which do the actual JWE encryption/decryption work by coordinating with the key and content encryption providers. CXF ships <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryption.java" rel="nofollow">JweEncryption</a> (JwsEncryptionProvider) and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweDecryption.java" rel="nofollow">JweDecryption</a> (JweDecryptionProvider) helpers, simply pass them the preferred key and content encryption providers and have the content encrypted or decrypted.</p><p>JweEncryption and JweDecryption help with creating and processing JWE Compact sequences (see the next section). 
JweEncryption can also help with streaming JWE JSON sequences (see JAX-RS JWE filters section).</p><p>Note that <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/AesCbcHmacJweEncryption.java" rel="nofollow">AesCbcHmacJweEncryption</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/AesCbcHmacJweDecryption.java" rel="nofollow">AesCbcHmacJweDecryption</a> providers supporting <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-5.2" rel="nofollow">AES_CBC_HMAC_SHA2</a> contet encryption are extending JweEncryption and JweDecryption respectively. They implement <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7518#section-5.2.2" rel="nofollow">the content encryption</a> internally but do
accept preferred key encryption/decryption providers.</p><p>Similarly, <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/DirectKeyJweEncryption.java" rel="nofollow">DirectKeyJweEncryption</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/DirectKeyJweDecryption.java" rel="nofollow">DirectKeyJweDecryption</a> are simple JweEncryption and JweDecryption extensions making it straighforward to do the direct key content encryption/decryption.</p><p><a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweUtils.java" rel="nofollow">JweUtils</a> utility class has a lot of helper methods to load key and and content encryption providers
and get the data encrypted and decrypted.</p><h3 id="JAX-RSJOSE-JWECompact">JWE Compact</h3><p><a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7516#section-3.3" rel="nofollow">JWE Compact representation</a> 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).</p><p><a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweCompactProducer.java" rel="nofollow">JweCompactProducer</a> and
<a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweCompactConsumer.java" rel="nofollow">JweCompactConsumer</a> offer a basic support for creating and consuming compact JWE sequences. In most cases you will likely prefer to use <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryption.java" rel="nofollow">JweEncryption</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweDecryption.java" rel="nofollow">JweDecryption</a> instead: <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryption.java" rel="no
follow">JweEncryption</a> uses JweCompactProducer internally when its <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryptionProvider.java#L27" rel="nofollow">encrypt</a> method is called (<a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweEncryptionProvider.java#L32" rel="nofollow">getEncryptedOutput</a> will be discussed in the JAX-RS JWE filters section), and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweDecryption.java" rel="nofollow">JweDecryption</a> accepts only JWE Compact and uses JweCompactConsumer internally.</p><p><a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/se
curity/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwe/JweJwtCompactProducer.java" rel="nofollow">JweJwtCompactProducer</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jws/JwsJwtCompactConsumer.java" rel="nofollow">JwsJwtCompactConsumer</a> help with directly encrypting typed JWT Tokens.</p><p>Here is the example of doing AES Key Wrap and AES CBC HMAC in CXF:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeHeader panelHeader pdl" style="border-bottom-width: 1px;"><b>CXF Jwe AesWrapAesCbcHMac</b></div><div class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">final String specPlainText = "Live long and prosper.";
AesWrapKeyEncryptionAlgorithm keyEncryption = new AesWrapKeyEncryptionAlgorithm(KEY_ENCRYPTION_KEY_A3, KeyAlgorithm.A128KW);
Modified: websites/production/cxf/content/docs/jax-rs-oauth2.html
==============================================================================
--- websites/production/cxf/content/docs/jax-rs-oauth2.html (original)
+++ websites/production/cxf/content/docs/jax-rs-oauth2.html Thu May 26 10:47:42 2016
@@ -118,11 +118,11 @@ Apache CXF -- JAX-RS OAuth2
<!-- Content -->
<div class="wiki-content">
<div id="ConfluenceContent"><h1 id="JAX-RSOAuth2-JAX-RS:OAuth2">JAX-RS: OAuth2</h1><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1458748017910 {padding: 0px;}
-div.rbtoc1458748017910 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1458748017910 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1464259620446 {padding: 0px;}
+div.rbtoc1464259620446 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1464259620446 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1458748017910">
+/*]]>*/</style></p><div class="toc-macro rbtoc1464259620446">
<ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-JAX-RS:OAuth2">JAX-RS: OAuth2</a></li><li><a shape="rect" href="#JAX-RSOAuth2-Introduction">Introduction</a></li><li><a shape="rect" href="#JAX-RSOAuth2-Mavendependencies">Maven dependencies</a></li><li><a shape="rect" href="#JAX-RSOAuth2-ClientRegistration">Client Registration</a></li><li><a shape="rect" href="#JAX-RSOAuth2-DevelopingOAuth2Servers">Developing OAuth2 Servers</a>
<ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-AuthorizationService">Authorization Service</a>
<ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-HowtocreateAuthorizationView">How to create Authorization View</a></li><li><a shape="rect" href="#JAX-RSOAuth2-EndUserNameinAuthorizationForm">EndUser Name in Authorization Form</a></li><li><a shape="rect" href="#JAX-RSOAuth2-PublicClients(Devices)">Public Clients (Devices)</a>
@@ -150,14 +150,14 @@ div.rbtoc1458748017910 li {margin-left:
<ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSOAuth2-Sharingthesameaccesspathbetweenendusersandclients">Sharing the same access path between end users and clients</a></li><li><a shape="rect" href="#JAX-RSOAuth2-Providingdifferentaccesspointstoendusersandclients">Providing different access points to end users and clients</a></li></ul>
</li><li><a shape="rect" href="#JAX-RSOAuth2-SingleSignOn">Single Sign On</a></li></ul>
</li></ul>
-</div><h1 id="JAX-RSOAuth2-Introduction">Introduction</h1><p>New:</p><ul style="list-style-type: square;"><li>OAuth2 module now depends on CXF cxf-rt-rs-security-jose module with the utility code in place to support a number of OAuth2 features depending on JOSE <br clear="none"><br clear="none"></li></ul><p>CXF provides the implementation of <a shape="rect" class="external-link" href="http://tools.ietf.org/html/rfc6749" rel="nofollow">OAuth 2.0</a>. See also the <a shape="rect" href="jax-rs-oauth.html">JAX-RS OAuth</a> page for information about OAuth 1.0.</p><p>Authorization Code, Implicit, Client Credentials, Resource Owner Password Credentials, Refresh Token and SAML2 Assertions grants are currently supported.</p><p>Custom grant handlers can be registered.</p><p>OAuth2 is a new protocol which offers a complex yet elegant solution toward helping end users (resource owners) authorize third-party providers to access their resources.</p><p>The OAuth2 flow which is closely related to
the original OAuth 1.0 3-leg flow is called Authorization Code and involves 3 parties: the end user, the third party service (client) and the resource server which is protected by OAuth2 filters. Typically a client offers a service feature that an end user requests and which requires the former to access one or more protected resources on behalf of this user which are located at the resource server. For example, the client may need to access the end user's photos in order to print them and post to the user or read and possibly update a user's calendar in order to make a booking.</p><p>In order to make it happen, the third-party service application/client needs to register itself with the OAuth2 server. This happens out-of-band and after the registration the client gets back a client key and secret pair. Typically the client is expected to provide the name and description of the application, the application logo URI, one or more redirect URIs, and other information that may help the
OAuth2 authorization server to identify this client to the end user at the authorization time.</p><p>From then on, the authorization code flow works like this:<br clear="none"> 1. End User requests the third-party service using a browser.</p><p>2. The client redirects the end user to OAuth2 Authorization Service, adding its client id, the state, redirect URI and the optional scope to the target URI. The state parameter represents the current end user's request, redirect URI - where the authorization code is expected to be returned to, and the scope is the list of opaque permissions that the client needs in order to access the protected resources.</p><p>3. Authorization Service will retrieve the information about the client using its client id, build an HTML form and return it to the end user. The form will ask the user if a given third-party application can be allowed to access some resources on behalf of this user.</p><p>4. If the user approves it then Authorization Service will ge
nerate an authorization code and redirect the user back to the redirect uri provided by the client, also adding a state parameter to the redirect URI.</p><p>5. The client requests an access token from OAuth2 Access Token Service by providing an authorization code grant.</p><p>6. After getting an access token token, the service finally proceeds with accessing the current user's resources and completes the user's request.</p><p>As you can see the flow can be complex yet it is very effective. A number of issues may need to be taken care along the way such as managing expired tokens, making sure that the OAuth2 security layer is functioning properly and is not interfering with the end user itself trying to access its own resources, etc.</p><p>Please check the <a shape="rect" class="external-link" href="http://tools.ietf.org/html/draft-ietf-oauth-v2" rel="nofollow">specification</a> and the <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/OAuth#OAuth_2.0" rel="nof
ollow">Wikipedia article</a> as well as other resources available on the WEB for more information you may need to know about OAuth2.</p><p>CXF JAX-RS gives the best effort to making this process as simple as possible and requiring only a minimum effort on behalf of OAuth2 server developers. It also offers the utility code for greatly simplifying the way the third-party application can interact with the OAuth2 service endpoints.</p><h1 id="JAX-RSOAuth2-Mavendependencies">Maven dependencies</h1><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div><h1 id="JAX-RSOAuth2-Introduction">Introduction</h1><p>New:</p><ul style="list-style-type: square;"><li>OAuth2 module now depends on CXF cxf-rt-rs-security-jose module with the utility code in place to support a number of OAuth2 features depending on JOSE <br clear="none"><br clear="none"></li></ul><p>CXF provides the implementation of <a shape="rect" class="external-link" href="http://tools.ietf.org/html/rfc6749" rel="nofollow">OAuth 2.0</a>. See also the <a shape="rect" href="jax-rs-oauth.html">JAX-RS OAuth</a> page for information about OAuth 1.0.</p><p>Authorization Code, Implicit, Client Credentials, Resource Owner Password Credentials, Refresh Token, SAML2 Assertions and JWT assertion grants are currently supported.</p><p>Custom grant handlers can be registered.</p><p>OAuth2 is a new protocol which offers a complex yet elegant solution toward helping end users (resource owners) authorize third-party providers to access their resources.</p><p>The OAuth2 flow which is clos
ely related to the original OAuth 1.0 3-leg flow is called Authorization Code and involves 3 parties: the end user, the third party service (client) and the resource server which is protected by OAuth2 filters. Typically a client offers a service feature that an end user requests and which requires the former to access one or more protected resources on behalf of this user which are located at the resource server. For example, the client may need to access the end user's photos in order to print them and post to the user or read and possibly update a user's calendar in order to make a booking.</p><p>In order to make it happen, the third-party service application/client needs to register itself with the OAuth2 server. This happens out-of-band and after the registration the client gets back a client key and secret pair. Typically the client is expected to provide the name and description of the application, the application logo URI, one or more redirect URIs, and other information tha
t may help the OAuth2 authorization server to identify this client to the end user at the authorization time.</p><p>From then on, the authorization code flow works like this:<br clear="none"> 1. End User requests the third-party service using a browser.</p><p>2. The client redirects the end user to OAuth2 Authorization Service, adding its client id, the state, redirect URI and the optional scope to the target URI. The state parameter represents the current end user's request, redirect URI - where the authorization code is expected to be returned to, and the scope is the list of opaque permissions that the client needs in order to access the protected resources.</p><p>3. Authorization Service will retrieve the information about the client using its client id, build an HTML form and return it to the end user. The form will ask the user if a given third-party application can be allowed to access some resources on behalf of this user.</p><p>4. If the user approves it then Authorization
Service will generate an authorization code and redirect the user back to the redirect uri provided by the client, also adding a state parameter to the redirect URI.</p><p>5. The client requests an access token from OAuth2 Access Token Service by providing an authorization code grant.</p><p>6. After getting an access token token, the service finally proceeds with accessing the current user's resources and completes the user's request.</p><p>As you can see the flow can be complex yet it is very effective. A number of issues may need to be taken care along the way such as managing expired tokens, making sure that the OAuth2 security layer is functioning properly and is not interfering with the end user itself trying to access its own resources, etc.</p><p>Please check the <a shape="rect" class="external-link" href="http://tools.ietf.org/html/draft-ietf-oauth-v2" rel="nofollow">specification</a> and the <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/OAuth#OAut
h_2.0" rel="nofollow">Wikipedia article</a> as well as other resources available on the WEB for more information you may need to know about OAuth2.</p><p>CXF JAX-RS gives the best effort to making this process as simple as possible and requiring only a minimum effort on behalf of OAuth2 server developers. It also offers the utility code for greatly simplifying the way the third-party application can interact with the OAuth2 service endpoints.</p><h1 id="JAX-RSOAuth2-Mavendependencies">Maven dependencies</h1><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;"><dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-rs-security-oauth2</artifactId>
- <version>2.7.5</version>
+ <version>3.1.7</version>
</dependency>
</pre>
-</div></div><h1 id="JAX-RSOAuth2-ClientRegistration">Client Registration</h1><p>Client Registration is typically done out of band (OAuth2 experts are also finalizing the dynamic client registration).<br clear="none"> The client registration service will offer an HTML form where the clients will enter their details, see a <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/common/Client.java">Client</a> bean for the currently supported properties. <br clear="none"> Note CXF may offer an abstract client registration service in the future to minimize the effort to get the custom registration service created from scratch.</p><h1 id="JAX-RSOAuth2-DevelopingOAuth2Servers">Developing OAuth2 Servers</h1><p>OAuth2 server is the core piece of the complete OAuth2-based solution. Typically it contains 2 services for:<br clear="none"> 1. Authorizing request tokens by asking the en
d users to let clients access some of their resources and returning the<br clear="none"> grants back to the client (Authorization Service)<br clear="none"> 2. Exchanging the token grants for access tokens (Access Token Service)</p><p>CXF offers several JAX-RS service implementations that can be used to create the OAuth2 servers fast: <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/services/AuthorizationCodeGrantService.java">AuthorizationCodeGrantService</a> and <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/services/ImplicitGrantService.java">ImplicitGrantService</a> for managing the redirection-based flows, as well as <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/m
ain/java/org/apache/cxf/rs/security/oauth2/services/AccessTokenService.java">AccessTokenService</a> for exchanging the grants for new tokens.</p><p>Note that some grants that do not require the redirection-based support, such as SAML2 one, etc, may only require an Access Token Service be operational.</p><p>All of these services rely on the custom <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/OAuthDataProvider.java">OAuthDataProvider</a> which persists the access tokens and converts the opaque scope values to the information that can be presented to the users. Additionally, <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/grants/code/AuthorizationCodeDataProvider.java">AuthorizationCodeDataProvider</a> is an OAuthDataProvider which can
keep temporary information about the authorization code grants which needs to be removed after the tokens are requested in exchange.</p><p>Writing your own OAuthDataProvider implementation is what is needed to get the OAuth2 server up and running. In many cases all you need to do is to persist or remove the Authorization Code Grant data, use one of the available utility classes to create a new access token and also persist it or remove the expired one, and finally convert the optional opaque scope values (if any are supported) to a more view-able information.</p><h2 id="JAX-RSOAuth2-AuthorizationService">Authorization Service</h2><p>The main responsibility of OAuth2 Authorization Service is to present an end user with a form asking the user to allow or deny the client accessing some of the user resources. CXF offers <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/
services/AuthorizationCodeGrantService.java">AuthorizationCodeGrantService</a> and <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/services/ImplicitGrantService.java">ImplicitGrantService</a> for accepting the redirection requests, challenging the end users with the authorization forms, handling the end user decisions and returning the results back to the clients.</p><p>One of the differences between the AuthorizationCode and Implicit flows is that in the latter case the grant is the actual access token which is returned as the URI fragment value. The way the end user is asked to authorize the client request is similar between the two flows. In this section we will assume that the Authorization Code flow is being exercized.</p><p>A third-party client redirects the current user to AuthorizationCodeGrantService, for example, here is how a redirection may happen:</p>
<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><h1 id="JAX-RSOAuth2-ClientRegistration">Client Registration</h1><p>Client Registration is typically done out of band, with the the dynamic client registration being also possible.<br clear="none"> The client registration service will offer an HTML form where the clients will enter their details, see a <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/common/Client.java">Client</a> bean for the currently supported properties. </p><h1 id="JAX-RSOAuth2-DevelopingOAuth2Servers">Developing OAuth2 Servers</h1><p>OAuth2 server is the core piece of the complete OAuth2-based solution. Typically it contains 2 services for:<br clear="none"> 1. Authorizing request tokens by asking the end users to let clients access some of their resources and returning the<br clear="none"> grants back to the client (Authorization Service)<br clear="none"> 2. Exchanging the token g
rants for access tokens (Access Token Service)</p><p>CXF offers several JAX-RS service implementations that can be used to create the OAuth2 servers fast: <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/services/AuthorizationCodeGrantService.java">AuthorizationCodeGrantService</a> and <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/services/ImplicitGrantService.java">ImplicitGrantService</a> for managing the redirection-based flows, as well as <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/services/AccessTokenService.java">AccessTokenService</a> for exchanging the grants for new tokens.</p><p>Note that some grants that do not
require the redirection-based support, such as SAML2 one, etc, may only require an Access Token Service be operational.</p><p>All of these services rely on the custom <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/OAuthDataProvider.java">OAuthDataProvider</a> which persists the access tokens and converts the opaque scope values to the information that can be presented to the users. Additionally, <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/grants/code/AuthorizationCodeDataProvider.java">AuthorizationCodeDataProvider</a> is an OAuthDataProvider which can keep temporary information about the authorization code grants which needs to be removed after the tokens are requested in exchange.</p><p>Writing your own AuthorizationCodeDataProv
ider or OAuthDataProvider implementation is what is needed to get the OAuth2 server up and running. In many cases all you need to do is to persist or remove the Authorization Code Grant data, use one of the available utility classes to create a new access token and also persist it or remove the expired one, and finally convert the optional opaque scope values (if any are supported) to a more view-able information.</p><p>CXF 3.1.7 ships JPA2 (<a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/JPAOAuthDataProvider.java" rel="nofollow">JPAOAuthDataProvider</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/grants/code/JPACodeDataProvider.java" rel="nofollow">JPACodeDataProvider</a>), Ehcache (<a shape="rect" class="external-link" href="h
ttps://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/DefaultEHCacheOAuthDataProvider.java" rel="nofollow">DefaultEHCacheOAuthDataProvider</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/grants/code/DefaultEHCacheCodeDataProvider.java" rel="nofollow">DefaultEHCacheCodeDataProvider</a>) and JCache ( (<a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/JCacheOAuthDataProvider.java" rel="nofollow">JCacheOAuthDataProvider</a> and <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/grants/code/JCacheCodeDataProvider.java" rel="nofollow">JCacheCo
deDataProvider</a>) provider implementations which take care of all the persistence tasks: saving or removing registered clients, tokens and code grants. These providers can be easily customized. Custom implementations can also extend  <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/provider/AbstractOAuthDataProvider.java" rel="nofollow">AbstractOAuthDataProvider</a> or <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/grants/code/AbstractCodeDataProvider.java" rel="nofollow">AbstractCodeDataProvider</a>  and only implement their abstract persistence related methods or further customize some of their code.</p><p> </p><h2 id="JAX-RSOAuth2-AuthorizationService">Authorization Service</h2><p>The main responsibility of OAuth2 Authorizati
on Service is to present an end user with a form asking the user to allow or deny the client accessing some of the user resources. CXF offers <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/services/AuthorizationCodeGrantService.java">AuthorizationCodeGrantService</a> and <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/services/ImplicitGrantService.java">ImplicitGrantService</a> for accepting the redirection requests, challenging the end users with the authorization forms, handling the end user decisions and returning the results back to the clients.</p><p>One of the differences between the AuthorizationCode and Implicit flows is that in the latter case the grant is the actual access token which is returned as the URI fragment value. The way the
end user is asked to authorize the client request is similar between the two flows. In this section we will assume that the Authorization Code flow is being exercized.</p><p>A third-party client redirects the current user to AuthorizationCodeGrantService, for example, here is how a redirection may happen:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: xml; gutter: false; theme: Default" style="font-size:12px;">Response-Code: 303
Headers: {Location=[http://localhost:8080/services/social/authorize?client_id=123456789&scope=updateCalendar-7&response_type=code
&redirect_uri=http%3A//localhost%3A8080/services/reservations/reserve/complete&state=1],