Author: buildbot
Date: Tue Sep 10 18:56:55 2019
New Revision: 1049922
Log:
Production update by buildbot for cxf
Modified:
websites/production/cxf/content/cache/docs.pageCache
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-oauth2.html
==============================================================================
--- websites/production/cxf/content/docs/jax-rs-oauth2.html (original)
+++ websites/production/cxf/content/docs/jax-rs-oauth2.html Tue Sep 10 18:56:55
2019
@@ -119,15 +119,15 @@ 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.rbtoc1553637437264 {padding: 0px;}
-div.rbtoc1553637437264 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1553637437264 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1568141773313 {padding: 0px;}
+div.rbtoc1568141773313 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1568141773313 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1553637437264">
+/*]]>*/</style></p><div class="toc-macro rbtoc1568141773313">
<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>
-<ul class="toc-indentation"><li><a shape="rect"
href="#JAX-RSOAuth2-OOBResponse">OOB Response</a></li><li><a shape="rect"
href="#JAX-RSOAuth2-SecurecodeacquisitionwithredirectURI">Secure code
acquisition with redirect URI</a></li></ul>
+<ul class="toc-indentation"><li><a shape="rect"
href="#JAX-RSOAuth2-OOBResponse">OOB Response</a></li><li><a shape="rect"
href="#JAX-RSOAuth2-PKCEsupport">PKCE support</a></li></ul>
</li><li><a shape="rect" href="#JAX-RSOAuth2-FormPostResponseMode">Form Post
Response Mode</a></li></ul>
</li><li><a shape="rect"
href="#JAX-RSOAuth2-AccessTokenService">AccessTokenService</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#JAX-RSOAuth2-AccessTokenTypes">Access Token Types</a>
@@ -226,7 +226,7 @@ Cookie=[JSESSIONID=1c289vha0cxfe],
<pre>GET
http://localhost:8080/services/social/authorize?client_id=mobileClient&response_type=code
</pre>
-</div></div><p>Assuming the 'mobileClient' has been registered as public one
with no secret and the service has been set up to support such clients, the end
user will get a chance to authorize this client the same way it can do
confidential clients, and after this user gets back a code (delivered directly
in the response HTML page by default) the user will enter the code securely
into the device which will then replace it for a time-scoped access token by
contacting AccessTokenService.</p><h4
id="JAX-RSOAuth2-SecurecodeacquisitionwithredirectURI">Secure code acquisition
with redirect URI</h4><p>The following <a shape="rect" class="external-link"
href="https://tools.ietf.org/html/draft-ietf-oauth-spop-15";
rel="nofollow">extension</a> is supported to help public clients with redirect
URIs to accept the code securely.</p><p>The public (mobile) client will include
a 'code_verifier' value when requesting the authorization code and it will be
saved by Authorization service, with the help
of the registered AuthorizationCodeDataProvider into an instance of
ServerAuthorizationCodeGrant. The client will next request a token providing
the 'code' and 'code_challenge' - the latter will be compared by
AuthorizationCodeGrantHandler with the original 'code_verifier'. By default,
the 'code_challenge' is expected to be equal to the original 'code_verifier',
but the grant handler can be registered with the custom
org.apache.cxf.rs.security.oauth2.grants.code.CodeVerifierTransformer - CXF
ships a DigestCodeVerifier which implements a transformation mentioned in the
extension.</p><h3 id="JAX-RSOAuth2-FormPostResponseMode">Form Post Response
Mode</h3><p><a shape="rect" class="external-link"
href="http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html";
rel="nofollow">Form Post Response Mode</a> has been orinially introduced for
OpenId Connect but has been generally recomended recently as a possibly safer
option of returning OAuth2 Authorization Service response to the cli
ents. Starting from CXF 3.1.9, if a client sends a "response_mode=form_post"
parameter during the original redirect, CXF AuthorizationCodeService will
return  <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/common/OOBAuthorizationResponse.java";
rel="nofollow">OOBAuthorizationResponse</a> with its 'redirectUri' property
set - a JSP/etc handler will convert to an HTML form which will re-post the
data to the client callback address.</p><h2
id="JAX-RSOAuth2-AccessTokenService">AccessTokenService</h2><p>The role of <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/services/AccessTokenService.java";
rel="nofollow">AccessTokenService</a> is to exchange a token grant for a new
access token which will be used by the client to access the end user's reso
urces. <br clear="none">Here is an example request log:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>Assuming the 'mobileClient' has been registered as public one
with no secret and the service has been set up to support such clients, the end
user will get a chance to authorize this client the same way it can do
confidential clients, and after this user gets back a code (delivered directly
in the response HTML page by default) the user will enter the code securely
into the device which will then replace it for a time-scoped access token by
contacting AccessTokenService.</p><h4 id="JAX-RSOAuth2-PKCEsupport">PKCE
support</h4><p>CXF supports <a shape="rect" class="external-link"
href="https://tools.ietf.org/html/rfc7636"; rel="nofollow">RFC-7636</a>: Proof
Key for Code Exchange by OAuth Public Clients (PKCE). If you are using the
authorization code grant with public clients, it is recommended to use PKCE to
avoid attacks which exploit the lack of a binding between the authorization
code request and the token request. This binding is achieved for confidential
clients by i
ncluding the client_id in both requests, however with public clients we do not
have a registered client_id.</p><p>The public (mobile) client generates a
'code_verifier' value and includes a related 'code_challenge' and optional
'code_challenge_method' to the authorization service. The authorization service
will save the code_challenge value, with the help of the registered
AuthorizationCodeDataProvider into an instance of ServerAuthorizationCodeGrant.
The client will next request a token providing the 'code_verifier' - which will
be compared by AuthorizationCodeGrantHandler with the original 'code_challenge'
value. By default, the 'code_challenge' is expected to be equal to the original
'code_verifier', but the grant handler can be registered with the custom
org.apache.cxf.rs.security.oauth2.grants.code.CodeVerifierTransformer - CXF
ships a DigestCodeVerifier which implements a transformation mentioned in the
extension.</p><h3 id="JAX-RSOAuth2-FormPostResponseMode">Form Post Respons
e Mode</h3><p><a shape="rect" class="external-link"
href="http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html";
rel="nofollow">Form Post Response Mode</a> has been orinially introduced for
OpenId Connect but has been generally recomended recently as a possibly safer
option of returning OAuth2 Authorization Service response to the clients.
Starting from CXF 3.1.9, if a client sends a "response_mode=form_post"
parameter during the original redirect, CXF AuthorizationCodeService will
return  <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/common/OOBAuthorizationResponse.java";
rel="nofollow">OOBAuthorizationResponse</a> with its 'redirectUri' property
set - a JSP/etc handler will convert to an HTML form which will re-post the
data to the client callback address.</p><h2
id="JAX-RSOAuth2-AccessTokenService">AccessTokenService</h2><p>The role of <a
shap
e="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/services/AccessTokenService.java";
rel="nofollow">AccessTokenService</a> is to exchange a token grant for a new
access token which will be used by the client to access the end user's
resources. <br clear="none">Here is an example request log:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default">Address:
http://localhost:8080/services/oauth/token
Http-Method: POST
