Antonio Ortells

Antonio is a Senior Product Manager at Okta, where he leads the strategy for the "plumbing" of modern identity: sessions and refresh tokens in Auth0. Drawing on his previous experience as a Solution Architect and Technical Account Manager, Antonio brings a deep, customer-first perspective to building seamless and secure identity solutions. He spends his days obsessing over session protection and developer experience, ensuring that security remains invisible yet robust. When he isn't mitigating session-based risks, you’ll find him cheering at a football stadium or at home baking a newfound cake recipe.

Senior Product Manager

Learn how to use session and refresh token metadata in Auth0 to track device context, manage security flags, and bridge the gap between oblivious and contextual identity management.

A Guide to Auth0 Session and Refresh Token Metadata

I stream, blog, and make youtube videos about tech stuff. I love coding, I love AI, and I love building stuff!

Staff Developer Advocate

Juan Cruz Martinez

deepu-sasidharan

Deepu is a polyglot developer, Java Champion, and OSS aficionado. He mainly works with Java, JS, Rust, and Golang. He co-leads JHipster and created the JDL Studio and KDash. He's a Principal Developer Advocate at Okta. He is also an international speaker and a published author.

Principal Developer Advocate

Deepu K Sasidharan

Learn how Auth0 Token Vault uses OAuth 2.0 Token Exchange to provide secure, delegated access, letting AI agents act on a user's behalf without handling refresh tokens.

Auth0 Token Vault: Secure Token Exchange for AI Agents

Maria-v

Maria Vasilevskaya is a leading Identity Defense Security Engineer at Okta. With her extensive experience in identity security, she has held diverse roles including security executive advisory, professional consulting services, identity and security solutions architecture, and solutions engineering. Her primary objective at Okta is to empower customers in maintaining robust security postures by offering expert assistance during critical incidents and providing strategic advice on implementing security practices to prevent future crises.

Principal Security Engineer

Maria Vasilevskaya

Learn how to improve refresh token security. Explore how to implement advanced token misuse and hijacking detection rules using the Auth0 Detection Catalog.

Refresh Token Security: Detecting Hijacking and Misuse with Auth0

Nelson Matias

As a Group Product Manager at Auth0, I focus on delivering innovative solutions that enhance security and user experience for both businesses and developers. With hands-on experience as a Developer, Consultant, and Solution Architect, along with years of working in Technical Account Management, I’m passionate about solving complex problems and shaping the future of identity management.
Outside of work, I often watch football, listen to music, or spend quality time with my kids.

Group Product Manager

Continuous Session Protection empowers customers to meet a wide range of session and refresh token security needs, including custom lifetimes and revocation capabilities. Let’s dive deeper into how these features can enhance your security strategy.

Continuous Session Protection Now Available for Enterprise Customers

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.

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

Majid Hajian

I am a Google Developer Expert and Media Developer Expert and a passionate software developer with years of developing and architecting complex web and mobile applications. my passions are Flutter, PWA, and performance. I love sharing my knowledge with the community by writing and speaking, contributing to open source, and organizing meetups and events.

Google Developer Expert

In this tutorial, you’ll learn how to enhance your Flutter apps by enabling authentication, supporting federated identity providers, adding authorization by introducing roles and permissions, all leveraging Auth0.

In the exercise from the previous section, you added Auth0 authentication to an existing Flutter app. This added a username/password authentication flow to the app. You also gave the app the ability to request and submit refresh tokens, which enhance the user experience by not requiring the user to authenticate every time they use the app.

This section will expand on the app by examining some useful Auth0 features:

* Refresh token rotation
* Social logins
* Managing your Auth0 account

> **Look for the 🛠 emoji if you’d like to skim through the content while focusing on the build and execution steps.**


## Add Refresh Token Rotation

When the app makes an authentication request to Auth0’s authentication server, it includes the `offline_access` scope. This causes the authentication server to issue a refresh token, which the app can use to re-authenticate without requiring the user to log in again. The app stores this token in the device’s secure storage.

While this enhances the app’s user experience, it also introduces risk. The refresh token is long-lived, and the app could use it as a “lifetime pass” to endlessly request new access tokens and keep the user logged in forever.

I highly recommend taking advantage of *Refresh Token Rotation* and *Automatic Reuse Detection* to help mitigate this risk. With these features enabled, each refresh token can be used only once. When the app exchanges its refresh token for a new access token, the authentication server also returns a new refresh token and invalidates the old one. 

Let’s enable these features!

🛠 Navigate to the **Applications** section of your Auth0 dashboard, select the **MJ Coffee** application, and then select its **Settings** tab. Scroll down the page to the **Refresh Token Rotation** section and turn on the **Rotation** and **Absolute Expiration** options:

![Turn on the “Rotation” and “Absolute Expiration” options.](https://images.ctfassets.net/23aumh6u8s0i/6EizPZZnkGjxoAOle1Q8eL/e06c99f4a49413572736bbf0f470436c/rotation_and_absolute_expiration.png)

It is recommended that you issue a refresh token that expires after a preset lifetime. The refresh token’s lifetime can be extended each time one is used to get a new access token or access token/refresh token pair.

There are two options for token lifetimes, and they can be set independently of each other:

- **Absolute Lifetime:** Enabling **Absolute Expiration** sets a specified *absolute lifetime* for the application’s refresh tokens. Refresh tokens can be exchanged for new access tokens during this lifetime. Once the token’s age goes past its lifetime, the user will need to re-authenticate in order to get a new access token. If **Absolute Expiration** is disabled, the refresh token has an indefinite absolute lifetime.
- **Inactivity Lifetime:** Enabling **Inactivity Expiration** specified *inactivity lifetime* for the application’s refresh tokens. Refresh tokens can be exchanged for new access tokens if the user is active in the application during this lifetime. If the user is inactive in the application for a period longer than the inactivity lifetime, they will need to re-authenticate in order to get a new access token.

🛠 Scroll to the bottom of the page and click the **Save Changes** button:

![The “Save Changes” button. The user is directed to click it.](https://images.ctfassets.net/23aumh6u8s0i/7KsLW4adJ6PNIPAI12al4g/f2c0e8abf6d7377595cfb7df11493e67/save_changes.png)


## Social Logins

These days, it's pretty common to have login methods beyond the standard username/password combination. These include logging in with social media account, which will significantly enhance your users’ experiences.

Implementing these additional login methods and adding them to your authorization server is time-consuming and will come with many considerations and risks. 

Luckily, Auth0 provides lots of integration with well-known third parties’ authentication systems, and even allows you to write your custom connections. Let's add connections to both Google’s and Apple’s authentication systems.


### Create a Google/Gmail social connection

🛠 In the Auth0 dashboard, select **Authentication** in the left column menu, then select **Social**. This takes you to the **Social Connections** page, where you should click the **Create Social Connection** button:

![The steps to create a new social connection in Auth0](https://images.ctfassets.net/23aumh6u8s0i/61w1eXrbY7bGOpNo6ODbaU/da810c63bacd28cabf71e6dee4baa349/create_social_connection.png)

You will be taken to the **New Social Connection** page, which has a list of social login providers that integrate with Auth0. 

🛠 Select **Google**:

![Selecting Google from all the available social connections](https://images.ctfassets.net/23aumh6u8s0i/2YdUxIkwmCTcc9QFlo584q/22f7fd0bf4bc1c93c4ebc555e21009f8/select_google.png)

You will now be on the  **New Google / Gmail Social Connection** page, which tells you what kind of user information is accessed by Google social login.

🛠 Click **Continue**:

![Initial page for creating a new Google/Gmail social connection](https://images.ctfassets.net/23aumh6u8s0i/2SQwtF0vqtXJucnGbE3DNS/baf5bd9d7103a6ecbd59b879bbe2aaf4/click_continue.png)

A new page with a number of fields will appear; this is the connection’s **Settings** tab. 

As long as you’re working in a development environment, you only need to fill the **Name** field (which provides a name for this connection) and leave all the other fields empty. You can always use the default value in the **Name** field:

![New Google/Gmail social connection](https://images.ctfassets.net/23aumh6u8s0i/7Jzsn4ryILOOdACN2urlSo/fdaa205ef09352c0b9aba0acbd592977/new_google_gmail_social_connection.png)

However, production apps require you to provide a **Client ID** and **Client Secret** ([doc](https://auth0.com/docs/connections/social/google)) and specify the **Allowed Mobile Client IDs**. These topics will be covered in another video or article.

🛠 Create the Google/Gmail connection by scrolling to the bottom of the page and clicking **Create**:

![Creating the Google/Gmail connection](https://images.ctfassets.net/23aumh6u8s0i/4S8AJUaj4xehVwVxhNDt5X/69eb88b8bec557d310d0e9d678fe9b7e/click_create.png)

This will create the connection, and you’ll be taken to its **Applications** tab. You’ll see a list of your applications, which will allow you to enable the Google/Gmail connection for any of them. Enable the connection for the *MJ Coffee* application:

![The Google/OAuth2 applications tab](https://images.ctfassets.net/23aumh6u8s0i/681u1RRcha4ABJJ5GRZivy/c7eea90ca4e19ec5ab3b333caa47e5ba/google-oauth2_applications_tab.png)

You may also set more permissions that the end-user will need to approve during authorization. These permissions depend on your application and what you want to do on behalf of the user. The *MJ Coffee* app doesn’t need any extra permissions beyond the basic and extended profile.

![Google Permission](https://images.ctfassets.net/23aumh6u8s0i/13CvLX8tQUTuqU6jpZ6K94/a0eaac13b8fc83fc11b3ca3f6651ebd9/google_permissions.png)

🛠 Make sure you sync user profile attributes at each login and hit the **Save** button.


### Create an Apple ID social connection

🛠 Once again in the Auth0 dashboard, select **Authentication** in the left column menu, then select **Social**. This takes you to the **Social Connections** page, where you should click the **Create Social Connection** button:

![The steps to create a new social connection in Auth0](https://images.ctfassets.net/23aumh6u8s0i/1sohaZxDHuq8X8ZvT5nhvE/d2b7a7e2647708327f8fc6971ddb43a9/create_connection.png)

🛠 This time, select **Apple**:

![Selecting Apple from all the available social connections](https://images.ctfassets.net/23aumh6u8s0i/3JAgbtDSNOsfYrjxkE1wCI/e51d80f7418706c29cd6e9dc06b93719/select_apple.png)

You will now be on the  **New Apple Social Connection** page, which tells you what kind of user information is accessed by Apple social login.

🛠 Click **Continue**:

![Continue](https://images.ctfassets.net/23aumh6u8s0i/3zt2ntLwoHwp6bldLmOOsD/8db3e7f5c057d5782c7202b748013420/click_connect_-_apple.png)

As long as you’re working in a development environment, you can leave the **Client ID** and **Client Secret Signing Key** fields empty. You *will* need proper keys for those fields when the app goes to production; [this document covers that topic in more detail](https://auth0.com/docs/connections/apple-siwa/set-up-apple).

The **Apple Team ID** and **Key ID** values are required:

![Google Permission](https://images.ctfassets.net/23aumh6u8s0i/2qNvT5zkxB1TY06ywkH5Re/7c46fa1399743de9e7bb05d1d804fab0/apple_dev.png)

* To get your Apple Team ID, you need an Apple Developer Account.
* To get a Key ID for your app, you need to register that app using your Apple Developer Account. 

🛠 Sign in to your Apple Developer Account, and go to the **Membership** page and make a note of your Team ID.

🛠 If you have a registered app, you can skip the following steps and jump to the list of tasks for creating a service ID. Otherwise, follow the steps below:

- In the Apple Developer Portal, go to **Certificates, IDs, & Profiles > Identifiers** and click the blue “plus” icon next to **Identifiers** to create a new App ID.
- Choose **App IDs** as the identifier type and click **Continue**.
- Provide a description and a Bundle ID in reverse-domain name format (e.g.: `com.mydomain.mjcoffee`).
- Scroll down and check **Sign In with Apple**.
- Click **Continue**, and then click **Register**.

🛠 Once the app is registered, it’s time to create a service ID:

- Return to the **Certificates, IDs, & Profiles** section, and click the blue “plus” icon next to **Identifiers**.
- Choose **Service IDs** and select **Continue**. Fill in the description and identifier (e.g.: `com.mydomain.mjcoffee`).
- After checking **Sign In with Apple**, select **Configure**, and define your Web Domain (e.g.: `com.mydomain.mjcoffee`) and your "Return URL". Ensure that your Return URL is your Auth0 domain and that it follows this format: `https://YOUR_AUTH0_DOMAIN/login/callback`.

![Return URL apple sign in](https://images.ctfassets.net/23aumh6u8s0i/5Wetff0Tutv55UXsYz0gKq/ab19cd3e48604aea314410d22d194982/callback_apple.png)

🛠 Finally: save, continue and then register the service.


#### Set up your Client Secret Signing Key

🛠 Follow these steps:

- Go to **Keys**, which is located in the **Certificates, Identifiers, & Profiles** section of your Apple developer dashboard.
- Select the blue “plus” icon to add a new key.
- Enter a **Key Name** and check the **Sign In with Apple** option.
- Select **Configure** to make sure the **Choose a Primary App ID** field is filled with the correct App ID.
- Select **Save, Continue**, and then **Register**.
- On the page to which you're redirected after registering, make a note of the Key ID. Then download the key; it will have a `.p8` filename extension.

🛠 Go back to your Apple social connection settings and paste the Key ID. Ensure the proper attributes are selected (Name, Email) and sync user profile at each login is enabled. Hit **Save**.


## Enable Social Connections

🛠 Once you have created all your social connections and set them up correctly, go back to your applications. Go to the **Connections** tab and enable your newly-made social connections:

![app social connections](https://images.ctfassets.net/23aumh6u8s0i/59SCRbiX055qDcmTSNwPVl/fa175f974ceb43515893f24f7747d549/app_social_connections.png)

As you can see, adding and removing social connections for your apps is now as simple and flicking a switch.

On the Flutter side, I have good news: you don’t need to implement anything there! 

Restart the app, log out, then try to log in. You’ll see this:

![app social connections](https://images.ctfassets.net/23aumh6u8s0i/4b6BIaeZ8EHcN1a3MYVOrF/91c9039cf0d56051c99397d1a7524a3e/social_buttons_flutter.png)

That's it! The login screen will now display social login buttons, and their login flows will be ready to use.


## Branding 

While it’s fine to use the default branding in development, you want the login page to be customized to your “look and feel” once the app’s in production.

Auth0 allows you to customize your login page through a number of options. You can change the look and feel of the login page by adding colors and logos, and you can customize the user notification part of the process as well: email templates, text messages, and so on. It’s all in the **Branding** section of the Auth0 dashboard:

![Auth0 branding](https://images.ctfassets.net/23aumh6u8s0i/7oq6VzFQ3nSUcStZTXvjQu/38d1e272f3bef751d9feaca704d580dc/branding.png)


### Add Roles

You may want to provide certain functionalities to the user based on their roles. This is easy with proper authorization server such as Auth0, which facilitates adding roles and specifying what users in each role are allowed to do. 

In the MJ Coffee app, there are three different roles:

- **Admin:** These are administrators, and they will have access to all the app’s functionality with full permissions.
- **Customer:** This is the default role for registered or logged-in users. They are limited to the app’s customer-facing features. You will automatically assign this role to all users upon registration or login, and you will learn how to do so later on in this tutorial.
- **Employee:** These are coffee shop employees. They can access the community screen to answer customer requests in the support chat, as well as other employee-facing features.

![Auth0 roles](https://images.ctfassets.net/23aumh6u8s0i/7nVdiU86TPCF1tLXrBg6ID/54a078bfe7d2382a6776c26adfc5cba4/roles.png)

You can add more roles to the app as the need arises.


## User Management in Auth0

Auth0 provides the infrastructure to store users and their information on its cloud database.

For the *MJ Coffee* app, Auth0’s cloud database is sufficient. One of Auth0’s goals is to reduce the cost of extra infrastructure maintenance and cost.

You can access users by selecting **User Management** in the left column menu of the Auth0 dashboard. The **Users** page allows you to create new users and manage your existing ones by changing their details, adding permissions and roles, or revoking their access.

![Auth0 users](https://images.ctfassets.net/23aumh6u8s0i/3O0JDGBqXHmPfrKaEavP2D/260c804cf50a308e696ecd9a446ab4a9/users.png)

When you open a user, you’ll see that Auth0 provides in-depth details about that user, including basic account data, metadata, their devices, and their history, which might be pretty helpful for debugging the application or investigating a particular user’s access activity, permissions, and roles.

![Auth0 user roles](https://images.ctfassets.net/23aumh6u8s0i/JcGTMspZ9hKtu9RAi4Oq9/257a692aa9a65cd12e96f645b56aafd1/user_roles.png)

Each user account stores some basic information about the user: name, email address, the date and time when the account was created, and so on. 

Additional information can be attached to a user by adding to these metadata stores:  their user metadata, which is a key-value structure for storing information about the user. You can also store information in the user_metadata or manipulating `app_metadata`, which helps to provide more information to the Flutter application while receiving user details.


## Moving Forward

In the next section of this tutorial, you will learn how to add real-time chat to the app.


Flutter Authentication and Authorization with Auth0, Part 2: Refresh Tokens, Social Logins, and More

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.


Achieving a Seamless User Experience with Refresh Token Inactivity Lifetimes

How Auth0 helps you securely maintain user sessions and engagement in the era of ITP


## TL;DR

 * The ability to maintain seamless experiences for end-users in Single Page Applications (SPAs) is often business-critical and can have an enormous impact on revenue.
 * New browser privacy controls adversely impact the user experience in SPAs by preventing access to third-party cookies, which are used for silent authentication.
 * Auth0 now offers an alternative--Refresh Token Rotation--that provides a secure method for using refresh tokens in SPAs while providing end-users with seamless access to resources without the disruption in UX caused by browser privacy technology like ITP.

## The Business Imperative

Maintaining an uninterrupted user experience without the need to continually log in is critical for continued engagement, conversion rates, and sustained revenue. If an end-user returns to your site and they are automatically authenticated, they are much more likely to make purchases because they can be shown relevant promotions, see items they may have left in their cart, and have one less barrier on the way to a successful checkout. According to a [2018 report from Accenture](https://www.accenture.com/t20171031T052156Z__w__/us-en/_acnmedia/PDF-34/Accenture-Pulse-Check-Dive-Key-Findings-Personalized-Experiences.pdf), 91% of consumers are more likely to shop with brands who **recognize, remember**, and provide relevant offers and recommendations.

This is especially important on mobile websites and in mobile applications, where having to re-enter credentials can be a nuisance and result in abandoned carts or users opting to access the content later (when they have time to remember/enter their credentials) rather than being able to do so at the moment. Anyone who’s made an impulse purchase on their phone after seeing something cool or remembering at the last minute that a loved one’s birthday is next week can attest to how nice it is to not have to provide username and password credentials in the throws of inspiration (or panic).

## OAuth2 and Securing SPA Access to APIs

Single Page Applications (SPAs) are everywhere, driven by the business needs for richer user experiences and exposed APIs for use by other services. Unfortunately, providing secure authentication in SPAs has a number of challenges based on your application’s use case. 

The former guidance of using the Implicit Grant to provide access tokens (ATs) to SPAs is fairly straightforward but carries with it several security risks that each require explicit mitigations you must account for. If you want a more detailed exposition on the challenges of using the Implicit Flow in SPAs, please read [this excellent treatise](https://auth0.com/blog/oauth2-implicit-grant-and-spa/) by the incomparable [Vittorio Bertocci](https://www.linkedin.com/in/vittoriobertocci).

Auth0’s guidance to date is to use the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](https://auth0.com/docs/flows/concepts/auth-code-pkce) in SPAs. This is a much more secure solution than the Implicit Flow, and when used in conjunction with [silent authentication](https://auth0.com/docs/api-auth/tutorials/silent-authentication), it ensures that SPAs can silently renew access tokens without interrupting the user experience.

This technique uses a hidden iframe to request a code from Auth0, leveraging the Auth0 session cookie to prove the user is authenticated, subsequently enabling the SPA to then exchange that code for a new AT without prompting the end-user. 

However, recent browser enhancements threaten the uninterrupted user experience businesses rely on. Browsers are building more capabilities to safeguard user privacy, including [Safari blocking access to all third-party cookies](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) and [Chrome’s commitment](https://techcrunch.com/2020/01/14/google-wants-to-phase-out-support-for-third-party-cookies-in-chrome-within-two-years/) to do so within two years. 

Beyond the marketing and tracking implications of these changes, which many people applaud, there are unfortunate impacts on how SPAs leverage OAuth to access resources. These advancements, unfortunately, mean that the technique of preserving an uninterrupted user experience via Code Flow with PKCE in conjunction with silent authentication are no longer feasible because the hidden iframe can no longer access the Auth0 session cookie.

## What About Refresh Tokens? 

Beyond silent authentication, another technique for getting new access tokens is to use Refresh Tokens (RTs), which are typically long-lived and are used to request new ATs after the shorter-lived ATs expire.  [Refresh Tokens](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/) are an elegant solution that is often used in native applications on mobile devices in conjunction with short-lived ATs to provide seamless UX without having to issue long-lived ATs. 

![Refresh Tokens]( https://images.ctfassets.net/23aumh6u8s0i/10MGE8a5mYfQ5B6vJQX7MW/4be95e14a614b51ab88c477a382fe710/01_RTs_ATs)
(Like our fancy icons?
[Learn more about Auth0’s free Identicons](https://auth0.com/blog/introducing-auth0-identicons-identity-icons/)!)

This is why you can access streaming video services on your smart TV without signing in after you complete the initial Device Authorization; RTs are getting new ATs for you all the time. 

Unfortunately, long-lived RTs are not suitable for SPAs because there is no persistent storage mechanism in a browser that can assure access by the intended application only. As there are vulnerabilities that can be exploited to obtain these high-value artifacts and grant malicious actors access to protected resources, using refresh tokens in SPAs has been strongly discouraged. 

So... Privacy technology is impeding the Code Flow with PKCE & silent authentication. Refresh tokens can’t securely be persisted in browsers for long periods of time. What can we do?

## Introducing Refresh Token Rotation

As previously mentioned, using RTs in SPAs was considered insecure because they typically have long lifetimes (hence, their use in retrieving new short-lived ATs) and browser storage is susceptible to token theft. However, there are acceptable mitigations outlined in the most recent [OAuth2 BCP for browser-based applications](https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05) stipulating that refresh tokens may be used provided that they adhere to [specific recommendations](https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-05#section-8), including having a maximum lifetime and requiring rotation to protect against malicious re-use.

_"The best practices doc states that another acceptable mechanism for protecting refresh tokens for use in public clients (not just browsers) is **refresh token rotation**, a feature that invalidates a refresh token and issues a new one whenever it is used to refresh an access token. Security-wise, that's a great feature."_

Reference: [https://auth0.com/blog/oauth2-implicit-grant-and-spa/](https://auth0.com/blog/oauth2-implicit-grant-and-spa/)

Auth0 is proud to announce that as of today, **Refresh Token Rotation with Reuse Detection** is available for all customers. With Refresh Token Rotation enabled, every time a client exchanges an RT to get a new AT, a new RT is also returned and the preceding RT is invalidated. This means you don’t need to worry about having a long-lived RT that, if compromised, could provide illegitimate access to resources. As RTs are continually exchanged and invalidated, the threat surface area is greatly reduced.

Auth0 makes it easy to get started with Refresh Token Rotation. You can enable it via API call or using the Auth0 Dashboard with just a few clicks.

![Refresh Token Rotation with Reuse Detection]( https://images.ctfassets.net/23aumh6u8s0i/5QNg54N5PHCx1Wkp40uI7D/e31f25ef32c16c04f256b773be2508c8/02_rotating-tokens)

RTR is supported for any application using the following flows:

 * OAuth2 Authorization Code Flow
 * OAuth2 Authorization Code Flow with Proof Key for Code Exchange (PKCE)
 * OAuth2 Device Authorization Grant (Device Flow)
 * Resource Owner Password Grant (ROPG)

The following diagram illustrates how Refresh Token Rotation is used in conjunction with the Authorization Code Flow with PKCE, but the general principle of getting a new refresh token with each exchange applies to all supported flows.

![RTR Sequence Diagram](https://images.ctfassets.net/23aumh6u8s0i/31zrZnDZ9lQVNE4Xsu0J2w/b7d7686b3764798eff19ce134229ae8b/03_RTR_Sequence_Diagram)

## Automatic Reuse Detection

When a client needs a new AT, it sends the RT with the request to Auth0 to get a new RT/AT pair. As soon as the new RT/AT pair is issued by Auth0, the RT used in the request is invalidated. This helps safeguard your application from replay attacks resulting from compromised RTs.

Without enforcing sender-constraint using techniques like mTLS or Proof of Possession that require the client to prove it is the same one originally authorized, which are not yet widely adopted, it’s impossible for the Authorization Server (AS) to know which actor is legitimate or malicious in the event of a replay attack. Therefore, it’s important that when a previously-used RT (already invalidated) is sent to the AS that the most recently issued RT is immediately invalidated as well, preventing any RTs in the same token family--all RTs descending from the original RT issued for the client--from being used to get new ATs.

Let’s consider the following scenario: 

1. Legitimate Client has RT1, and RT1 is leaked to or stolen by Malicious Client. 
2. Legitimate Client uses RT1 to get a new RT/AT pair.
3. Auth0 returns RT2/AT2.
4. Malicious Client then attempts to use RT1 to get an access token. Auth0 recognizes that RT1 is being reused, and immediately invalidates the RT family, including RT2 because the reappearance of RT1 is indicative of token leakage. It is important that RT2 is also invalidated to prevent any subsequent damage, such as the attacker gaining access to that token.
5. Auth0 returns an Access Denied response to Malicious Client.
6. AT2 Expires and Legitimate Client attempts to use RT2 to request a new RT/AT pair. 
7. Auth0 returns an Access Denied response to Legitimate Client. Re-authentication is required.


![RTR Token Family](https://images.ctfassets.net/23aumh6u8s0i/4sQHivXQ1DSIYiySY7LfBx/69640b448b38980cb8433341e4fe646a/04_RTR_Token_Family)

This protection mechanism works regardless of whether the legitimate client or the malicious client is able to exchange RT1 for a new RT/AT pair before the other. As soon as reuse is detected, all subsequent requests will be denied until the user re-authenticates. And when reuse is detected, Auth0 captures this event in logs to provide visibility for security reviews/audits. This can be especially useful in conjunction with Auth0’s new log streaming capabilities.

This means that you can safely use RTs to mitigate the adverse effects of browser privacy tools and provide continuous access to end-users without disrupting the user experience.

## A Little Leeway Sometimes Helps

To ensure that re-use detection doesn’t adversely affect users that suffer intermittent network performance, we’ve also included a **configurable reuse interval** to account for scenarios where the tokens issued from Auth0 are not received before the client application retries using the original refresh token. This is especially important in cases where users may be on slower cellular connections or congested networks.

For example, a client application has a refresh/access token pair (RT1 & AT1). AT1 is short-lived and expires. The client needs to use RT1 to get a new AT. The client sends RT1 to Auth0, but experiences a network error before getting a response from Auth0, and never receives AT2 or RT2. So the client retries a few seconds later using RT1 again (the only RT it currently has in its possession). Without a sufficient reuse interval configured, Auth0 would recognize the retry as a reuse attempt, invalidate the entire RT family, and require a re-authentication. 

By configuring a reuse interval, you can account for known network issues based on your use-cases, such as scenarios where the client is accessed on a mobile device with spotty connectivity. Should you choose to configure a reuse interval, the safest practice is to use the shortest amount of time to afford protection from replay attacks.

## SDK Support

The following SDKs are updated to include support for Refresh Token Rotation:

 * [Auth0 SPA SDK (1.7.0)](https://auth0.com/docs/libraries/auth0-spa-js)
 * [Auth0 Swift (iOS) SDK (1.23.0)](https://auth0.com/docs/libraries/auth0-swift)
 * [Auth0 Android SDK (1.23.0)](https://auth0.com/docs/libraries/auth0-android)

The Auth0 SPA SDK previously did not support refresh tokens of any kind, until today. Now, you can enable the use of rotating RTs and successfully mitigate the effects of browser privacy tools when performing silent authentication. 

One additional security feature that has been included is the ability for the SDK to leverage web workers to make requests to the token endpoint and store new RTs. This makes it much harder for malicious actors to retrieve refresh tokens straight out of the in-memory store.

In addition, we now enable the developer to opt-in to storing tokens in either local storage or browser memory, the default being the latter.

You can read more about all of the new features in the [SDK documentation](https://auth0.com/docs/libraries).

## Let’s Get Started

As of April 15, 2020, Refresh Token Rotation is available for all Auth0 customers. You can read more about Refresh Token Rotation and how to configure it for use in your applications in the [Auth0 documentation](https://auth0.com/docs/tokens/concepts/refresh-token-rotation). We hope that you find this new capability helpful for sustaining user sessions and maintaining engagement in this era of heightened user privacy tools.

Stay healthy. Stay safe. And secure your SPAs!

<include src="asides/AboutAuth0" />


"refresh token"