Refresh Token:

The Refresh Token grant type is used by clients to exchange a refresh token for an access token when the access token has expired.

This allows clients to continue to have a valid access token without further interaction with the user.

This section describes how to allow your developers to use refresh tokens to obtain new access tokens. If your service issues refresh tokens along with the access token, then you’ll need to implement the Refresh grant type described here.

The refresh grant can only be used with confidential clients that have a client secret

• (A) The client requests an access token by authenticating with the authorization server and presenting an authorization grant.

• (B) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token and a refresh token.

• (C) The client makes a protected resource request to the resource server by presenting the access token.

• (D) The resource server validates the access token, and if valid, serves the request.

• (E) Steps (C) and (D) repeat until the access token expires. If the client knows the access token expired, it skips to step (G); otherwise, it makes another protected resource request.

• (F) Since the access token is invalid, the resource server returns an invalid token error.

Request Parameters

The access token request will contain the following parameters.

• grant_type (required): The grant_type parameter must be set to “refresh_token”.

• refresh_token (required): The refresh token previously issued to the client.

• scope (optional): The scope requested by the application.

Client Authentication (required if the client was issued a secret)

Typically, refresh tokens are only used with confidential clients. However, since it is possible to use the authorization code flow without a client secret, the refresh grant may also be used by clients that don’t have a secret. If the client was issued a secret, then the client must authenticate this request. Typically the service will allow either additional request parameters client_id and client_secret, or accept the client ID and secret in the HTTP Basic auth header. If the client does not have a secret, then no client authentication will be present in this request.

Example

The following is an example refresh grant the service would receive.

POST  /token-srv/token HTTP/1.1
Host: 
grant_type=refresh_token
&refresh_token=xxxxxxxxxxx
&client_id=xxxxxxxxxx
&client_secret=xxxxxxxxxx
&scope=profile

Response

The response to the refresh token grant is the same as when issuing an access token. You can optionally issue a new refresh token in the response, or if you don’t include a new refresh token, the client assumes the current refresh token will continue to be valid.

For example, a successful token response may look like the following:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"bearer",
  "expires_in":86400,
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
  "scope":"profile",
  "state":"12345678"
}