Access tokens and refresh tokens
What are access tokens?
- Access tokens are credentials for accessing protected resources
- It is a string that represents that the client has been authorized by the server i.e. the resource owner, to access protected resources
- Different access tokens may have specific scopes and durations of access
Uses and advantages
- Access token is used to access protected resources
- They provide an abstraction layer where we do not have to use authorization constructs like username and password anymore. These are replaced with a single ‘token’ which can be easily understood by the resource server.
What are the advantages of using tokens?
- Access tokens provide an abstraction layer where we do not have to use authorization constructs like username and password anymore.
- The resource server no longer needs to understand the various types of authentication methods — A single ‘access token’ replaces them entirely
- Access tokens can have different formats, structures, and methods of utilization e.g., cryptographic properties based on the resource server security requirements.
What are refresh tokens?
- Refresh tokens are credentials that are used to obtain an access token from the authorization server.
- A refresh token is a string representing the authorization granted to the client by the resource owner.
Usage
- Refresh tokens are used to obtain a new access token when the access token becomes expires
How are refresh tokens different from access tokens?
- Refresh tokens are intended for use only with authorization servers
- Refresh tokens are never sent to resource servers
- Refresh tokens are optional entities — Issuing a refresh token is optional and is always at the discretion of the authorization server
What are the other uses of refresh tokens?
- Refresh tokens are used to obtain a new access token when the access token becomes invalid or it expires
- Refresh tokens are also used to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner)
Flow:
+--------+ +---------------+
| |--(A)------ Authorization Grant ------->| |
| | | |
| |<-(B)--------- Access Token ------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)-- Access Token---> | | | |
| | | | | |
| |<-(D)- Protected Resource--| Resource | | Authorization|
| Client | | Server | | Server |
| |--(E)--- Access Token ---->| | | |
| | | | | |
| |<-(F)- InvalidTokenError-- | | | |
| | +----------+ | |
| | | |
| |--(G)-------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token ----------| |
+--------+ & Optional Refresh Token +---------------+(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.
(G) The client requests a new access token by authenticating with the authorization server and presenting the refresh token. The client authentication requirements are based on the client type and on the authorization server policies.
(H) The authorization server authenticates the client and validates the refresh token, and if valid, issues a new access token (and, optionally, a new refresh token).
