Skip to main contentArrow Right

As secure as access tokens are for authenticating user sessions, they're not without their limitations – notably, their short lifespan. This is where refresh tokens come into play, serving as a long-lived counterpart to the temporary access tokens. 

In this article, we'll dive into the purpose of refresh tokens, their operational dynamics, and why they're essential for maintaining secure and uninterrupted user sessions.

What is a refresh token?

A refresh token is a special kind of token that is used to generate a new access token. It's like a spare key that lets users obtain a new key (access token) once the old one expires, without the users needing to re-authenticate. These tokens are crucial for long-term authentication and provide a seamless user experience, particularly in mobile and web applications where users expect to remain logged in across sessions.

A refresh token typically looks like a random string, similar in appearance to an access token, but it is used exclusively for obtaining new access tokens. Here is an example of what a refresh token might look like:

eyJhbGciOiJSUzI1NiIsImtpZCI6IlAyU0FjMk91NGw5ZDVHbHBZV3lVWlJZdE5ITTYiLCJ0eXAiOiJKV1QifQ.eyJhbXIiOlsic21zIl0sImRybiI6IkRTUiIsImV4cCI6MTcwMjA2MTE3NiwiaWF0IjoxNjk5NjQxOTc2LCJpc3MiOiJQMlNBYzJPdTRsOWQ1R2xwWVd5VVpSWXROSE02Iiwic3ViIjoiVTJWaXNjT0paM0xrQ1RxNHZtd3FQYklIUm1DeSJ9.cCyklhGh9ACvYvkpy94a4dncodr0ApWma-UNbWoeS-7VuZyf1s1d5Zyjn_nDWaLBko3LouRue9Q-J1sM6MiznJSup1cgJ9ygXUAOckCbM-iT8eQCEucrc33JeCrVurcluX6g3e9VYdgxPw8iEoRbZMCgPOIEzbQheFwcyRxHcl-OkQw2A88hwQHElwIl-5RK4tG5aS94r-k10tPKIR02G0TmUWEirqGD0GqM28o_Shl2VnUwDW5nSEKSgxA7zHmqHLg2WKUOGPkbyg120gFF0KxCh-NgR-kE0yIgveyPGjpXIneFGKf5zOXVnDDc8hwKxW9nQGV4GlgQmmSn1DLTRA

This string is a JSON Web Token (JWT) that contains encoded JSON objects with data about the refresh token. The actual structure and information in the token can vary depending on the authorization server's implementation. However, they typically contain information such as the user ID, the type of token (indicating it's a refresh token), and the issuance and expiry timestamps.

After decoding the token you’ll see a payload like this:

{
  "amr": [
    "sms"
  ],
  "drn": "DSR",
  "exp": 1702061176,
  "iat": 1699641976,
  "iss": "P2SAc2Ou4l9d5GlpYWyUZRYtNHM6",
  "sub": "U2ViscOJZ3LkCTq4vmwqPbIHRmCy"
}

To quickly cover what these fields mean:

  1. `amr` (Authentication Methods Reference): Like the access token, this array indicates the methods used for authentication. It's less common in refresh tokens unless the system specifically needs to remember the method of authentication when issuing a new access token.

  2. `exp` (Expiration Time): This indicates the time when the token will expire. Refresh tokens typically have a longer lifespan than access tokens.

  3. `iat` (Issued At): This signifies when the token was issued, which can be used to determine its age and possibly to enforce policies like refresh token rotation after a certain time period.

  4. `iss` (Issuer): This is the signature of the issuing entity, which could be an authorization server. It's critical for the client application to verify that the token has been issued by a trusted authority.

  5. `sub` (Subject): This identifies the entity that is the subject of the token. The refresh token is essentially linked to this identity, ensuring that only this user can use it to obtain new access tokens.

The relationship between access tokens and refresh tokens

While access tokens are the actual "keys" to accessing resources, refresh tokens are the "renewal mechanism" for these keys. They work hand in hand to streamline the user's experience by reducing the need for repeated logins while maintaining a high level of security.

How does a refresh token work?

Access and refresh tokens are usually used in the context of OAuth 2.0 and OpenID Connect. Here’s a simplified flow of how a refresh token works:

  1. Initial login: The user logs in through a client application, which authenticates the credentials against an authentication server.

  2. Token issuance: Once authenticated, the server issues both an access token and a refresh token to the client.

  3. Access token use: The access token is used for accessing protected resources until it expires.

  4. Access token expiry: Upon expiration, the client will use the refresh token to obtain a new access token.

  5. New token grant: The authorization server validates the refresh token and issues a new access token (and possibly a new refresh token).

Benefits and best practices

Here are the main benefits of using refresh tokens:

  • Continuous access: Users enjoy uninterrupted access to applications without frequent re-logins.

  • Enhanced security: Long-lived refresh tokens reduce the risk of access token theft, as the tokens used to access resources are short-lived and expire quickly.

  • Improved user experience: By minimizing the need for users to re-enter their credentials, refresh tokens offer a more seamless interaction with applications.

For these tokens to be effective at fulfilling their stated goals, some thought needs to be put into their implementation. Here are some best practices to follow:

  • Secure storage: Refresh tokens should be stored securely and never exposed to the client side to prevent unauthorized use.

  • Rotation policy: Implementing a token rotation policy where a new refresh token is issued with every access token refresh can reduce the risk of token theft.

  • Revocation mechanism: Ensure there’s a system in place to revoke refresh tokens when necessary, such as when a user logs out, changes their password, or if there is a suspicion of token compromise.

When to use refresh tokens

Refresh tokens should be used in situations where you need to maintain a user session over extended periods without requiring the user to repeatedly log in with their credentials. 

Here are some scenarios where refresh tokens are particularly useful:

  • Long-lived sessions: For applications that require the user to stay logged in across multiple days or weeks, like mobile and desktop applications, or single-page applications (SPAs) that do not refresh the entire page.

  • Background processes: When an application needs to perform operations in the background without user interaction, such as checking for new emails or syncing data.

  • Reduced latency: In cases where the application needs to access protected resources without the added latency of a full authentication round-trip to the server.

  • Increased security: Since access tokens can be short-lived, using refresh tokens can limit the exposure window of potentially compromised access tokens.

  • Third-party access: For situations where an application needs to access user data from a third-party service over an extended period, as with many "Sign in with X" services.

  • Federated identity: When you're using a federated identity service where the identity provider is separate from the resource server, refresh tokens can minimize the need for frequent re-authentication against the identity provider.

Conclusion

Refresh tokens play an indispensable role in modern authentication processes by ensuring that user sessions can be maintained securely and efficiently. By understanding and implementing these tokens in your security architecture, you can enhance both the security and the user experience of your applications.

Interested in integrating authentication and authorization into your app? Leverage Descope’s no-code CIAM platform to easily add AuthN, AuthZ, and identity management to apps using drag-and-drop workflows, SDKs, and APIs. Sign up for a Free Forever account or schedule a consultation with our authentication experts to get started.