peterfernandez_360

As an Architect, Consultant, and Engineer, I have more than 30 years of experience designing and developing secure and robust software solutions. When not helping teams deal with the complexities of Customer Identity, you can usually find me working behind the scenes, acting in or directing a show at my local theatre.

Principal Developer Advocate

Peter Fernandez

A step-by-step guide to leveraging OAuth 2.0 Refresh Tokens in an iOS app built with Swift and integrated with Auth0.

Using a Refresh Token in an iOS Swift App

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Andrea Chiarelli

Learn the best practices for securing ID, access, and refresh tokens in your .NET MAUI applications and keeping a consistent user experience.

Managing Tokens in .NET MAUI

Learn why and how to use refresh tokens in ASP.NET Core applications.

Use Refresh Tokens in ASP.NET Core Apps

37590801?s=460&v=4

A software engineer who dreams about non-electric sheep and autonomous vehicles and likes to champion security.

Software Engineer

Dan Arias

Sam4-square

I'm an Identity nerd with many years of experience as a developer and advocate. I love explaining complex topics clearly and understandably. You can find me on stage at developer events worldwide or simply having great conversations in the hallway. Google has recognized me as a Google Developer Expert (GDE) in the domains of Web Technologies, Security, Privacy, Payments, and Identity.

Sam Bellen

Learn about refresh tokens and how they help developers balance security and usability in their applications.

What Are Refresh Tokens and How to Use Them Securely

randy_nasson

Director of Product Management for Customer Identity Cloud (formerly Auth0) in our Identity and Access Management (IAM) domain. I joined Auth0 in 2018 and assembled a world-class IAM product team dedicated to delivering customer value and enabling developers to quickly implement secure, robust, and seamless identity solutions. In addition to my current work with CIC, I regularly work with our Auth0 Lab team on greenfield initiatives and with our Strategic and Technical Partner teams on opportunities to drive revenue.

Director, Product Management (IAM)

Randy Nasson

Delight users while providing a secure CIAM solution for accessing applications and services



## Summary

* Refresh tokens [can be effectively used for maintaining a seamless user experience](https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/) 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**
<br /><br />

## 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](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/) 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](https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/) and [Automatic Reuse Detection](https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/#Automatic-Reuse-Detection), refresh tokens can safely be used in Single Page Applications (SPAs) to afford continuous access on the web.

![Refresh Token](https://images.ctfassets.net/23aumh6u8s0i/6lBzS4ElN5ZEULvNM50Hvi/1a84f912b03d26661286ec71b4016f71/01-image-refresh-token)

## 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)](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.12.2) 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.

![Introducing Inactivity Lifetime](https://images.ctfassets.net/23aumh6u8s0i/6vutURQweArCulYsO5eBvL/f54e0ef9f358058bde3b185c474ab814/04-at-expiration-1-day-flow)

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](https://auth0.com/docs/api/management/v2#!/Clients/post_clients), our [Deploy CLI](https://auth0.com/docs/extensions/deploy-cli-tool), or the Auth0 Dashboard.

![Auth0 Management API](https://images.ctfassets.net/23aumh6u8s0i/4P5VvuP2z41wvUoBDlRzvH/840a1ebbbf639eb0827ad62b4ab645c2/05-refresh-token-expiration)

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](https://auth0.com/docs/tokens/refresh-tokens/refresh-token-rotation#automatic-reuse-detection). 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).

![Auth0 Management API](https://images.ctfassets.net/23aumh6u8s0i/1og3ppkzZWZlMEXh1NNqLM/c2f2998f7509d6568fd87ca40622fdcf/06-refresh-token-expiration-2)

## 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: 

![Confidential Clients](https://images.ctfassets.net/23aumh6u8s0i/3ZABGcvqKpo7NIanSD1v4e/c83ca317f6483ccae212a9ac2db827fb/07-confidential-clients)

### 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: 

![Public Clients](https://images.ctfassets.net/23aumh6u8s0i/5sUFHqXRJ1OQZnb4MvMOMu/62b5e02b574bbe4c1b74cfee434d628e/08-public-clients)

### 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:

![SPAs](https://images.ctfassets.net/23aumh6u8s0i/1S9d6u2w8dgSZ4D3cEpwIa/b0d00b921376cf6ec28bb86ac5f95145/09-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](https://auth0.com/docs/tokens/refresh-tokens/configure-refresh-token-expiration). 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.


"refresh-token"