Summary
- Refresh tokens can be effectively used for maintaining a seamless user experience in browser-based apps without suffering the limitations imposed by ITP2
- Configuring absolute lifetimes for refresh tokens helps reduce the risk of using RTs in single-page applications
- Inactivity lifetime enables refresh token lifetimes to be extended as long as the end-user interacts with the client within the configured period, resulting in less end-user friction
- Auth0 now provides both absolute and inactivity lifetimes for refresh tokens, along with more secure refresh token defaults, as of December 16, 2020
Balancing Security and User Experience
Most businesses want to afford a friction-free experience for end-users when using their applications. Requiring people to manually enter credentials every time they visit a commerce site or open an app can yield frustration and hurt the business bottom line. A common request in business-to-consumer (B2C) industries is to only require users to log in once and then to never require them to log in again unless they are explicitly logged out, either by choice or necessity.
The practice of using long-lived refresh tokens paired with short-lived Access Tokens is a common solution to delivering an uninterrupted experience, particularly in native mobile apps. With additional security capabilities such as Refresh Token Rotation and Automatic Reuse Detection, refresh tokens can safely be used in Single Page Applications (SPAs) to afford continuous access on the web.
Refresh Token Expiration
However, a refresh token is considered a powerful artifact in identity management. If a refresh token is leaked or stolen, it could be used to acquire a new Access Token. As such, the OAuth 2.0 Best Current Practices (BCP) states that refresh tokens should expire if the application (client) is inactive for too long, particularly when used in Public Clients (a client that cannot secure its own credentials, such as a native mobile app). This means that refresh tokens should expire at some point in time, but that expiration can be based on activity and not merely an arbitrary point in the future.
When the refresh token expires, it can no longer be used to get a new Access Token. The user will be required to re-authenticate the next time they use the application. More importantly, an attacker’s window for using a leaked token is limited.
But, what about the business desire for only wanting the end-user to log in once and not again thereafter? For SPAs, this can still be afforded within the OAuth 2.0 BCP guidance provided that the end-user’s activity in the application remains consistent.
Let’s consider an example: A media company publishes content on a regular basis that is only available to authenticated subscribers. In addition, the company sells subscriptions and related goods (books, print media, access to premium video content, etc.) using stored payment methods associated with the account.
In this scenario, the website is a SPA with Auth0 as the authorization server, and refresh tokens are used to overcome the session limitations incurred by ITP2 or similar privacy mechanisms. Because there is sensitive information in the account, maintaining an indefinite application session is not ideal.
Leveraging absolute lifetimes, end-users can be required to log in again after a predetermined period of time. But that experience is not optimal for the business or the end-user. Requiring re-authentication creates friction between the user and the content or purchases. What if the user could remain logged in as long as they were active in the application on a regular basis, for example, once every two weeks?
Introducing Inactivity Lifetime
Unlike absolute lifetime, which expires a refresh token after a fixed period, inactivity lifetime extends the expiration period each time the client uses a refresh token to get a new access token. Using the example above, this effectively preserves the seamless user experience as long as there is an activity within the inactivity lifetime.
As of today, both absolute and inactivity lifetimes for refresh tokens are available for all Auth0 customers hosted in our cloud environment and will be available in December 2020 for private cloud customers. This enables you to configure refresh token lifetimes based on your own app usage data, for example, by evaluating your application log data to determine how often users return to your app so that people who use applications regularly can have that period extended as long as usage remains consistent.
Auth0 makes it easy to configure refresh token lifetimes using the Auth0 Management API, our Deploy CLI, or the Auth0 Dashboard.
Inactivity lifetime can be used in all supported refresh token flows and in conjunction with Refresh Token Rotation.
Using Inactivity and Absolute Lifetimes Together
Both inactivity and absolute lifetimes can be configured on a per-application basis, enabling you to craft experiences to suit the expected usage of your applications.
Setting absolute lifetimes for refresh tokens ensures that refresh tokens cannot be used to retrieve a new access token after the specified period. For example, if you set the absolute lifetime to 30 days, the refresh token issued to the application can be used for up to 30 days from its issuance to retrieve a new access token. If you are leveraging Refresh Token Rotation, the absolute lifetime applies to the entire token family. After the lifetime expires, the user will be required to re-authenticate.
You can also use a combination of absolute and inactivity lifetimes to afford an uninterrupted user experience for much longer durations, provided that the user remains active within the inactivity lifetime. For example, you can set the absolute lifetime to 365 days and the inactivity lifetime to 14 days. This would allow a user who was active in your application at least once every two weeks to continuously stay logged in until the absolute lifetime expires.
You can also use an inactivity lifetime without an absolute lifetime in a similar manner to achieve the effect of never having to log in again as long as the user remains active within the inactivity lifetime (and the user never explicitly logs out).
Guidance & Defaults
As part of Auth0’s continued commitment to securing applications and protected resources, we’ve updated default refresh token settings for new applications as follows.
Confidential Clients
Confidential clients, such as machine-to-machine applications or traditional web applications that can securely store client credentials and can, therefore, prove that requests are coming from the client and not an illegitimate actor. As such, when refresh tokens are enabled, for confidential clients, default settings are optimized for convenience as follows:
Public Clients (Native Apps)
Because Public Clients, such as native mobile applications, cannot securely store client credentials and are susceptible to other attack vectors when refresh tokens are enabled for public clients, the default settings are optimized for security, as follows:
SPAs
Until recently, refresh tokens were not recommended for use with SPAs because browsers are more vulnerable to token leakage than native applications. Leveraging Refresh Token Rotation, the risk of using refresh tokens in SPAs is lowered. Nevertheless, Auth0 recommends that SPAs use refresh tokens with Absolute lifetimes specified and sets the following defaults when refresh tokens are enabled for SPAs:
Let’s Get Started
As of December 16, 2020, both absolute and inactivity lifetimes for refresh tokens are available for all Auth0 customers hosted in our cloud environment and will be available in December 2020 for private cloud customers. You can read more about refresh token expiration, absolute lifetimes, and inactivity lifetimes and how to configure them for use in your applications in the Auth0 documentation. We hope that you find this new capability helpful for balancing user experience with added security.
Secure the applications that you care about. But do it in a way that delights the people who use them.