The final step for the client is to swap the authorization code received in the previous step for an access token that can be used to authorize access to resources. By limiting the exposure of the access token to a direct HTTPS connection between the client application and the authorization endpoint, the risk of exposing this access token to an unauthorized party is reduced.

For this to occur, the client makes a HTTP POST request to the token endpoint on the AS. This request will use the following parameters sent in the body of the request:

Item Description
grant_type Required to be "authorization_code"
code The authorization code received in the previous step
redirect_uri If this was included in the authorization request, it MUST also be included

This request should also authenticate as the pre-configured client using either HTTP BASIC authentication or by including the client_id and client_secret values in the request.

To retrieve the access token in the example, the following request will be made:


POST https://localhost:9031/as/token.oauth2 HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Authorization: BasicYWNfY2xpZW50OjJGZWRlcmF0ZQ==

grant_type=authorization_code
  &code=XYZ...123
      

A successful response to this message will result in a 200 OK HTTP response and the access token (and optional refresh token) returned in a JSON structure in the body of the response.



HTTP/1.1 200 OK

Content-Type: application/json;charset=UTF-8

{
   "access_token":"zzz...yyy",
   "token_type":"Bearer",
   "expires_in":14400,
   "refresh_token":"123...789"
}

      

The application can now parse the access token and, if present, the refresh token to use for authorization to resources. If a refresh token was returned, it can be used to refresh access token once it expires.