What is a Refresh Token

• Access token: short-lived (5-15 min), sent on every request
• Refresh token: long-lived (30+ days), only to token endpoint
• Rotation: on refresh use, a new refresh is issued and old is revoked
• Revocation list: Redis/DB with invalidated tokens
• Grace period: 30 sec for race conditions on concurrent refreshes

POST /oauth/token
  grant_type=refresh_token
  refresh_token=XXX
  client_id=Y
→ { access_token: "...", refresh_token: "NEW", expires_in: 900 }

• JWT
• OAuth 2.0
• PKCE

Refresh tokens are a crucial component of the OAuth 2.0 authorization framework, designed to enhance security and user experience. In the OAuth 2.0 flow, after a user successfully authenticates, they receive both an access token and a refresh token. The access token is typically short-lived, while the refresh token has a longer lifespan, allowing the client to request new access tokens without requiring user re-authentication.

The workflow is as follows:

• The client application requests access by redirecting the user to the authorization server.
• Upon successful authentication, the authorization server issues an access token and a refresh token.
• The client uses the access token to access protected resources for a limited time.
• Once the access token expires, the client sends a POST request to the token endpoint with the refresh token.
• The authorization server validates the refresh token and issues a new access token, allowing seamless continuation of the session.

This flow minimizes the need for users to log in frequently, thus enhancing user experience while maintaining security through the limited lifespan of access tokens.

Secure storage of refresh tokens is critical to maintaining the integrity of user sessions and protecting against unauthorized access. Here are some best practices for storing refresh tokens:

• Use httpOnly Cookies: Store refresh tokens in httpOnly cookies to prevent client-side scripts from accessing them. This mitigates risks from Cross-Site Scripting (XSS) attacks.
• Avoid Local Storage: Do not store refresh tokens in localStorage or sessionStorage, as these are accessible via JavaScript and can be exploited by malicious scripts.
• Implement Token Expiration: Set an expiration time for refresh tokens, ensuring that even if they are compromised, they will eventually become invalid.
• Use Secure Attributes: When using cookies, ensure they are marked as Secure to prevent transmission over unencrypted connections.
• Limit Scope and Permissions: Generate refresh tokens with the minimum necessary scope and permissions to reduce potential damage from a compromised token.

By adhering to these practices, developers can significantly enhance the security surrounding refresh tokens, thus protecting both user data and application integrity.

Implementing refresh tokens in your application involves several steps, from generating tokens to using them for access. Below is a practical example using a hypothetical API endpoint.

1. Requesting Tokens: After the user successfully logs in, you can request access and refresh tokens:

2. Response: The server responds with an access token and a refresh token:

3. Using the Access Token: Use the access token to access protected resources:

4. Refreshing the Access Token: When the access token expires, use the refresh token to obtain a new access token:

5. New Access Token Response: The server issues a new access token:

By following this example, developers can effectively manage user sessions without requiring frequent logins, leveraging the power of refresh tokens in their applications.