The Refresh Token in Oauth2.0

The Refresh Token in Oauth2.0

1.Concept

The biggest difference between Oauth2.0 and Oauth1.0 is the acquirement of access token, the access token of Oauth1.0 can be stored in the database and used for long time, the validity period is basically infinite, which result in its insecurity. The access token of And Oauth2.0 is valid for a short period, Therefore, Oauth2.0 brought in refresh token.

In the oauth2.0, authorization code obtained the token and the default validity period is 1 hour (authorization code is disposable, once used and it will be invalid), so to use the refresh token, when we acquire access token with the authorization code, the code also send a refresh token to us, which is used to refresh it, it cannot be used to request the API, it is used to refresh the access token after the expiration of a access token.

2.Scenario

For example, we call a Microsoft Graph API, the server will release a valid access token, but also released a long-period refresh token. When a user makes a request for another network, the access token is added to the request body (no refresh token is required). If the access token expires during the request process, the corresponding status code is returned. Then callback a callback method, the original access token and refresh token will be sent to the server in the callback method body, to acquire new access token and refresh token (because the refresh token and authorization code are disposable). And then add the new access token to the request, reload the request.

The refresh token appears in two modes:

Authorization code:

Specific steps are as follows:

  1. The user accesses the client, and the client directs the user to the authorization authority.
  2. The user chooses whether to grant client authorization.
  3. Assuming that the user is authorized, the authorization server directs the user to the redirection URI specified by the client in advance, with an authorization code.
  4. The client receives the authorization code, with the previous redirection URI, to the authorization server to apply for a token.
  5. The authorization server checks the authorization code and the redirection URI, and sends an access token and a refresh token to the client.

User+Password code:

Specific steps are as follows:

  1. The user provides the user with the user name and password.
  2. The client sends the user name and password to the authentication server and requests the token from the latter.
  3. After the authentication server is correct, provide the access token and refresh token to the client.

3.Request and Response example

Request:

The refresh token request must be in the form of an HTTP POST message.

POST /common/oauth2/v2.0/token HTTP/1.1

Host: https://login.microsoftonline.com

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

client_id=d217413b-1440-4222-8a7b-128668f22a2e

&scope=user.read%20mail.read

&refresh_token=AQABAAAAAAF9kYklhVy4SJTGZzR-p1BciQLGyRMTztIE5G4d1hsb-Z…

&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F

&grant_type=refresh_token

&client_secret=8bueNhbLYbcmO6sRfn89gjM

 

Response:

{

“access_token”:”eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlZXVkljMVdEMVRrc2J…”,

“token_type”: “Bearer”,

“expires_in”: 3599,

“scope”: “user.read%20mail.read”,

“refresh_token”: “AQABAAAAAAA9kTklhVy7SJTGAzR-p1BcLdUZX33T7uR2Mb2dcRRt7…”,

}

Note: If you get the access-token, but can’t the refresh token, and the end-user must identify himself every hour. Then your scope must lack of offline_access. The offline_access scope gives your app access to resources on behalf of the user for an extended time. If your app does not request the offline_access scope, it won’t receive refresh tokens. This means that when you redeem an authorization code in the OAuth 2.0 authorization code flow, you’ll receive only an access token from the /token endpoint.

5.Instance code

Here’s code snippet of refresh token:

string signedInUserID = ClaimsPrincipal.Current.FindFirst(ClaimTypes.NameIdentifier).Value;

string Aauthority = “https://login.microsoftonline.com/common/”;

AdalTokenCache Atokencache = new AdalTokenCache(signedInUserID,new HttpContextWrapper(HttpContext.Current));

Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredential clientcred = new Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredential(appidv1, appSecretv1);

string resourceid = “https://graph.microsoft.com”;

AuthenticationContext ac= new AuthenticationContext(Aauthority, Atokencache);

//can’t see refresh token here, AuthenticationContext cache the refresh token

Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationResult token_result =

Await ac.AcquireTokenSilentAsync(resourceid, clientcred, UserIdentifier.AnyUser);

var tk = token_result.AccessToken;

return token_result.AccessToken;

In the above code snippet about the calling of AcquireTokenSilentAsync:

The ADAL cache refreshes the token and automatically uses the refresh token whenever you call AcquireToken and the requested token needs to be updated (even if you want to get a new access token for a different resource).

5.Summary

With a refresh token, if the access token is compromised because it is short, the attacker has a limited window to abuse it. It does not matter if the refresh token is compromised, because in addition to the refresh token, the attacker also needs the client ID and password to get the access token.

In the case of no refresh token:

  1. Send an API request with an access token
  2. If the access token is invalid, it fails and requires the user to re-authenticate

In the case of a refresh token:

  1. Send an API request with an access token
  2. If the access token is invalid, try using the refresh token to update it
  3. If the refresh request passes, update the access token and resend the initial API request
  4. If the refresh request fails, request the user to re-authenticate

The benefits of refresh_token are obvious.

Leave a Reply

Your email address will not be published. Required fields are marked *