What is the purpose of a refresh token?

Auth & identity

January 28, 2022

Author: Julianna Lamb

When it comes to authorization, developers must carefully-balance security with user experience. On the one hand, if protocols are too stringent, a user can become frustrated. On the other, if authorization is too lax, a security breach is all but inevitable. Fortunately, there’s a solution that fulfills both needs—refresh tokens.

In this post, we’ll explain how refresh tokens work, the benefits they offer for session management, and advanced security measures to consider as you implement them.

What are refresh tokens? How do you use them?

Used within the OAuth 2.0 authorization framework, refresh tokens are a sophisticated method for controlling the length of user sessions within native, web-based, or single-page applications.

Essentially, refresh tokens allow a user to stay logged in for a longer period of time without having to repeat the authentication process, such as by entering their password. This creates a better user experience and provides an extra security layer for sensitive information.

Understanding different types of tokens

A token is a data artifact that can be used to verify a user’s identity. You can think of tokens as digital signatures. There are two main types of tokens that developers can use for authorization:

ID tokens

ID tokens are especially relevant in OAuth 2.0 and its close relative Open ID Connect (OIDC) (common in single sign on authentication flows). We won't go into those in-depth here, but in these transactions the ID token is issued whenever a user logs in. It contains information like a user's name, email, or other factors that may be important. In SSO authentication processes, the ID token confirms the user’s identity is genuine.

Access tokens

Access tokens are credentials for the user to access protected resources such as secured APIs. These tokens are issued by an authorization server and typically have a short lifespan (minutes or hours). Once the access token expires, the user will need to re-authenticate to receive a new access token.

Refresh tokens

Refresh tokens have a longer lifespan (weeks, months, years, even infinite) and are used to automatically request a new access token from the authorization server when the current access token expires. It’s important to note that refresh tokens on their own do not provide the user with any access.

Benefits of refresh tokens

Incorporating refresh tokens can help developers strike the optimal balance between a seamless UX and stepped-up security measures to protect sensitive data. The three main benefits of refresh tokens include:

Uninterrupted user experience

Refresh tokens extend session duration to prevent unnecessary reauthentication. For example, if an access token is only valid for 10 minutes, but the user is on the application for 15 minutes, the session may abruptly terminate. Clearly, this is not ideal and can lead to poor customer retention. A better approach is to use a refresh token, which enables new access tokens to be issued without a delay or additional user effort.

Seamless background activity

Refresh tokens can also be used to make API calls on behalf of the user. The app can receive access tokens in the background without the user intervening or even being present.

Improved security

The use of refresh tokens makes it feasible to shorten the lifespan of access tokens. Since an access token is a bearer token, any user (legitimate or malicious) that possesses it is considered authenticated without any additional identification. The longer the access token remains valid, the higher the risk of it becoming compromised or stolen. Pairing long-duration refresh tokens with short-duration access tokens enhances security without compromising the user experience.

How is a refresh token generated and used?

Refresh tokens are generated by the authorization server at the same time that access tokens are issued. When a user logs in to the application, the following sequence is initiated between the user, authorization serve, and resource server:

The user successfully completes the authorization process.
The authorization server gives an access token and refresh token to the user.
The user provides the access token to the resource server.
The resource server validates the access token, then provides the user with access to the protected resource.
When the access token expires, the user presents the refresh token to the authorization server.
The authorization server validates the refresh token, then provides the user with a new access token.
The user provides the resource server with the new access token to maintain access without restarting the authorization process.

This process of replacing asset tokens continues until one of the following occurs:

The refresh token expires
The user logs out to end the session
The refresh token is revoked or invalidated by the authorization server
The developer institutes a new authentication policy

Improving security with refresh token rotation and automatic reuse detection

Since refresh tokens are intended for long-time use, it’s imperative that they don’t fall into the wrong hands. When a hacker possesses an active refresh token, they have free reign to issue access token requests until the refresh token expires or is revoked. Allowing illegitimate access to your environment can have devastating consequences. Fortunately, developers can add two additional security measures to their refresh tokens:

Refresh token rotation (RTR)

Also called RTR, refresh token rotation turns a refresh token into a one-time-use token. When a refresh token is used, the authentication server provides a new access token as well as a new refresh token. For the duration of the session, refresh tokens are continually exchanged instead of the same token being used repeatedly.

Automatic reuse detection

With RTR, automatic reuse detection is designed to cut off access when a refresh token is deemed compromised. If a hacker gains possession of a refresh token, there’s a good chance the genuine user will use it before the hacker attempts to get a new access token. When the authentication server recognizes that a refresh token was returned for a second time, that token is flagged. In response, the unauthorized user is denied access, and the entire refresh token family is invalidated.

Alternative methods for session management (besides refresh tokens)

Refresh tokens aren’t the only option that developers have for extending user sessions. However, each alternative comes with a concerning drawback:

Silent authenticating (also called continuous authentication) retrieves a new access token if the user still has a valid session, but requires an embedded iframe, which are largely considered an outdated approach.
Cookies can be blocked by modern browser privacy settings such as Intelligent Tracking Prevention (ITP).
Sender constrained tokens require the user to answer a secret security question, interrupting the UX.

Considerations for building and using refresh tokens

When building refresh tokens for your application, several factors can impact their utility and security:

When does the access token expire?

As previously mentioned, the inclusion of a refresh token allows you to shorten the life of an access token without impacting the user experience. The sooner the access token expires, the more refresh flows you may need—but that is often a small price to pay for additional security.

Does the refresh token expire?

A refresh token can remain active indefinitely, or you can set expiry terms based on when the token is issued or the level of inactivity (when it was last used to obtain a new access token).

What safeguards are in place for XSS attacks?

Refresh tokens can be vulnerable to cross-site scripting (XSS). Be sure to follow best practices for testing and preventing these types of cyber attacks.

Where is the token being stored?

Storing refresh tokens in the backend provides the highest level of security. Using the browser’s local storage offers the added benefit of maintaining sessions after a page refresh or a closed browser tab—however, this approach is more vulnerable to XSS and should only be considered when RTR and automatic reuse detection are implemented.