Introduction

CXF 2.5.0 implements OAuth 1.0. Please also see the JAX-RS OAuth2 about the OAuth2 support in CXF.

While OAuth 2.0 (which is very close to becoming the final recommendation) is the next major version of OAuth, OAuth 1.0 has been implemented by many providers and the CXF OAuth 1.0 module should make it easy for developers to start writing OAuth 1.0 applications.

OAuth 1.0 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 resou rce 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 flow works like t his:
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 use r'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 noted above, the consumer needs to register first with the OAuth server. It's a good practice to provide an application name and so called connect URI which is typically a public URI of this application; the former will be used by OAuth Authorization Service at step 4 above and the latter will be used at step 2 to validate the provided callback URI to make sure it starts from the URI which was actually provided during the registration.

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 pr operly and is not interfering with the end user itself trying to access its own resources, etc.

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.

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.

Maven dependencies

+