[CONF] Apache CXF Documentation > JAX-RS OAuth

[confluence]

JAX-RS OAuth Page edited by Sergey Beryozkin Changes (5) ... CXF 2.5.0 implements [OAuth 1.0|http://tools.ietf.org/html/rfc5849]. While [OAuth 2.0|http://oauth.net/2/] (which is very close to becoming the final recommendation) is the next major version of OAuth, OAuth 1.0 is being supported by many providers and the CXF OAuth module should make it easy for developers to start writing OAuth applications, be it OAuth 1.0 or OAuth 2.0 once the latter gets implemented. OAuth offers a complex yet elegant solution toward enabling helping the end users (resource owners) to authorize third-party providers to access their resources. The classical OAuth flow is also called a 3-leg OAuth flow as it involves 3 parties: The classical OAuth flow is also called a 3-leg OAuth flow as it involves 3 parties: the end user (resource owner), the third party service (client, consumer) and the resource server which is protected by OAuth filters. Typically a consumer offers a service feature that an end user requests and which requires the former to access one or more resources of this end user which are located at the resource server. For example, the consumer 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. In order to make it happen, the third-party service application/consumer needs to register itself with the OAuth server. This happens out-of-band and after the registration the consumer gets back a consumer key and secret pair. For example, see this page for one [approach|http://code.google.com/apis/accounts/docs/RegistrationForWebAppsAuto.html]. The registrations of third-party application does not have to be very involved for simpler applications. From then on, the typical flows works like this: 1. End User requests the third-party service using a browser. 2. Third-party service requests a temporarily request token from OAuth RequestToken Service; this token will represent a consumer's intention to access whatever end user resources it needs to complete the current user's request. 3. After getting a request token back, the consumer redirects the end user to OAuth Authorization Service and adds the request token to the target URI. 4. Authorization Service will get all the details about the current consumer using a request token, 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. 5. If the user approves it then Authorization Service will redirect the user back to the callback uri provided by the consumer when requesting a request token, including a generated verifier (authorization key) which 'links' the user's approval with the request token. 6. Now the third-party service requests an access token from OAuth AccessToken Service by providing a request token and its verifier. 7. After getting an access token token, the service finally proceeds with accessing the current user's resources and completes the user's request. As you can see the flow can be complex yet it is functional. A number of issues may need to be taken care along the way such as managing expired tokens, making sure that the OAuth security layer is functioning properly and is not interfering with the end user itself trying to access its own resources, etc. CXF JAX-RS gives the best effort to making this process as simple as possible and requiring only a minimum effort on behalf of OAuth server developers. It also offers the utility code for greatly simplifying the way the third-party application can interact with the OAuth service endpoints. Now, as far this particular 3-leg flow is concerned, OAuth 2.0 simplifies it by effectively making the steps 3 and 6 (requests for request and access tokens) redundant. Moving to OAuth 2.0 will be straightforward after learning how to build OAuth 1.0 servers with CXF. Please check the [specification|http://tools.ietf.org/html/rfc5849] and the [Wikipedia article|http://en.wikipedia.org/wiki/OAuth] as well as other resources available on the WEB for more information you may need to know about OAuth. ... </dependency> {code} h1. Developing OAuth Servers h1. Client-side support h1. Design considerations h2. Sharing the same URI path between end users and consumers h1. 3-leg flow on the wire Full Content JAX-RS: OAuth Introduction Maven dependencies Developing OAuth Servers Client-side support Design considerations Sharing the same URI path between end users and consumers 3-leg flow on the wire Introduction CXF 2.5.0 implements OAuth 1.0. While OAuth 2.0 (which is very close to becoming the final recommendation) is the next major version of OAuth, OAuth 1.0 is being supported by many providers and the CXF OAuth module should make it easy for developers to start writing OAuth applications, be it OAuth 1.0 or OAuth 2.0 once the latter gets implemented. OAuth offers a complex yet elegant solution toward helping the end users (resource owners) authorize third-party providers to access their resources. The classical OAuth flow is also called a 3-leg OAuth flow as it involves 3 parties: the end user (resource owner), the third party service (client, consumer) and the resource server which is protected by OAuth filters. Typically a consumer offers a service feature that an end user requests and which requires the former to access one or more resources of this end user which are located at the resource server. For example, the consumer 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. In order to make it happen, the third-party service application/consumer needs to register itself with the OAuth server. This happens out-of-band and after the registration the consumer gets back a consumer key and secret pair. For example, see this page for one approach. The registrations of third-party application does not have to be very involved for simpler applications. From then on, the typical flows works like this: 1. End User requests the third-party service using a browser. 2. Third-party service requests a temporarily request token from OAuth RequestToken Service; this token will represent a consumer's intention to access whatever end user resources it needs to complete the current user's request. 3. After getting a request token back, the consumer redirects the end user to OAuth Authorization Service and adds the request token to the target URI. 4. Authorization Service will get all the details about the current consumer using a request token, 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. 5. If the user approves it then Authorization Service will redirect the user back to the callback uri provided by the consumer when requesting a request token, including a generated verifier (authorization key) which 'links' the user's approval with the request token. 6. Now the third-party service requests an access token from OAuth AccessToken Service by providing a request token and its verifier. 7. After getting an access token token, the service finally proceeds with accessing the current user's resources and completes the user's request. As you can see the flow can be complex yet it is functional. A number of issues may need to be taken care along the way such as managing expired tokens, making sure that the OAuth security layer is functioning properly and is not interfering with the end user itself trying to access its own resources, etc. CXF JAX-RS gives the best effort to making this process as simple as possible and requiring only a minimum effort on behalf of OAuth server developers. It also offers the utility code for greatly simplifying the way the third-party application can interact with the OAuth service endpoints. Now, as far this particular 3-leg flow is concerned, OAuth 2.0 simplifies it by effectively making the steps 3 and 6 (requests for request and access tokens) redundant. Moving to OAuth 2.0 will be straightforward after learning how to build OAuth 1.0 servers with CXF. Please check the specification and the Wikipedia article as well as other resources available on the WEB for more information you may need to know about OAuth. Maven dependencies <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-rs-security-oauth</artifactId> <version>2.5.0</version> </dependency> Developing OAuth Servers Client-side support Design considerations Sharing the same URI path between end users and consumers 3-leg flow on the wire Change Notification Preferences View Online | View Changes | Add Comment