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.
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.
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 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 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 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.
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:
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.
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.
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:
This process of replacing asset tokens continues until one of the following occurs:
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.
Refresh tokens aren’t the only option that developers have for extending user sessions. However, each alternative comes with a concerning drawback:
When building refresh tokens for your application, several factors can impact their utility and security:
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.
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).
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.
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.
With Stytch’s session management, you can use refresh tokens to provide a seamless and secure user experience.