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],
