OAuth 2.0 Demystified: Tokens

The OAuth 2.0 Authorization Framework defines two token types viz., an Access Token and a Refresh Token. Let's take a look at each of these tokens...

Access Token

Access Tokens are issued by the Authorization Server after authorization has been obtained from the Resource Owner. Access Tokens are used to access Protected Resources.

An Access Token provides a set of scopes and a duration for which access is granted to the Protected Resource which is enforced by the Authorization and Resource Servers.

Such an Access Token may be a simple identifier or, it may take the form of a JSON Web Token (JWT).

Access Tokens are convenient because it replaces different authorization constructs (such as username and password) with a single token that is understood by the Resource Server. In other words, the Resource Server does not need to understand a wide range of different authorization methods.

Access Tokens are usually provided as a Bearer Token in the Authorization header of a request, for example:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

Refresh Token

A Refresh Token is issued by the Authorization Server together with an Access Token. This Refresh Token is a credential that is used to obtain another Access Token when the current Access Token becomes invalid or expires.

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"mF_9.B5f-4.1JqM",
    "token_type":"Bearer",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}

The Refresh Token is only used by Authorization Server and the Client and is never sent to the Resource Server.

Have you ever seen a website that asks you whether you want to extend your session? That popup appears when the Access Token is about to expire. If you agree to have your session extended, the Client will send the Refresh Token to the Authorization Server and a new Access Token will be issued with a new expiry time.