The role of AccessTokenService 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. Here is an example request log:
Address: http://localhost:8080/services/oauth/token
Http-Method: POST
Headers: {
Accept=[application/json],
Authorization=[Basic MTIzNDU2Nzg5Ojk4NzY1NDMyMQ==],
Content-Type=[application/x-www-form-urlencoded]
}
Payload:
grant_type=authorization_code&code=5c993144b910bccd5977131f7d2629ab
&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fservices%2Freservations
%2Freserve%2Fcomplete
This request contains a client_id and client_secret (Authorization header), the grant_type, the grant value (code) plus the redirect URI the authorization grant was returned to which is needed for the additional validation. Note that the alternative client authentication methods are also possible, in this case the token service will expect a mapping between the client credentials and the client_id representing the client registration available.
After validating the request, the service will find a matching AccessTokenGrantHandler and request to create a ServerAccessToken which is a server-side representation of the access token. The grant handlers, such as AuthorizationCodeGrantHandler may delegate the creation of the actual access token to data providers, which may create Bearer or MAC tokens with the help of utility classes shipped with CXF or depend on other 3rd party token libraries.
The data providers are not strictly required to persist the data such as access tokens, instead the token key may act as an encrypted bag capturing all the relevant information.
Now that the token has been created, it is mapped by the service to a client representation and is returned back as a JSON payload:
Response-Code: 200
Content-Type: application/json
Headers: {
Cache-Control=[no-store],
Pragma=[no-cache],
Date=[Thu, 12 Apr 2012 14:36:29 GMT]
}
Payload:
{"access_token":"5b5c8e677413277c4bb8b740d522b378", "token_type":"bearer"}
The client will use this access token to access the current user's resources in order to complete the original user's request, for example, the request to access a user's calendar may look like this:
Address: http://localhost:8080/services/thirdPartyAccess/calendar
Http-Method: GET
Headers:
{
Authorization=[Bearer 5b5c8e677413277c4bb8b740d522b378],
Accept=[application/xml]
}
Note that the access token key is passed as the Bearer scheme value. Other token types such as MAC ones, etc, can be represented differently.