DEV Community

Cover image for ## Understanding Access Token and Refresh Token Flow
Sonam Jamtsho
Sonam Jamtsho

Posted on

## Understanding Access Token and Refresh Token Flow

Securing your app's APIs is crucial, and a robust token-based authentication system is key. But how does it all work, especially when it comes to keeping users logged in without compromising security? 🤔

Let's break down the typical Access Token and Refresh Token flow:

1.Initial Login: When a user logs in, the server validates their credentials. If they're correct, the server issues two tokens:

  • Access Token: This is a short-lived token (minutes to an hour). It's what your frontend sends with every API request to prove the user's identity.

  • Refresh Token: This is a long-lived token (days or weeks). It's not used for API calls. Its sole purpose is to get a new access token once the current one expires.

2.Making API Calls: For every protected resources, the frontend sends the access token in the Authorization header. The backend quickly validates it, and if it's valid, the request is processed.

3.Token Expiration: The magic happens when the access token expires. Instead of forcing the user to log in again, the frontend's API client (often an interceptor) detects the "401 Unauthorized" error. Instead of informing the client about 401 error, it starts the refresh token flow.

4.The Refresh flow: The client uses the refresh token to call a dedicated /refresh endpoint on the backend. If the refresh token is valid and hasn't been revoked or expired, the backend issues a brand new pair of tokens - a new access token and a new refresh token. The old refresh token is then invalidated, which is a critical step for security.

5.Seamless User Experience: The frontend updates its stored tokens and retries the original failed API request with the new access token. All of this happens seamlessly in the background, providing a smooth, uninterrupted user experience while maintaining a high level of security by keeping access tokens short-lived.

Where should the refresh token be stored?
Since refresh tokens are long-lived and need to be easily revoked, they should be kept in a secure, persistent data store.

  • Database: This is the most common and recommended approach. A dedicated table in your database can store the refresh token hash, along with a link to the user and metadata like the expiration date and IP address. Hashing the token is crucial to protect against data breaches. This method also makes it easy to revoke a token by simply deleting its database entry.

  • Redis or In-Memory Cache: For high-traffic applications, a fast key-value store like Redis is an excellent option. You can store the refresh token hash as a key with an appropriate time-to-live (TTL). This provides a very fast lookup during the token refresh process.

Storing refresh tokens in a database or secure cache is critical for enabling revocation and ensuring the integrity of the authentication flow.

Image credit: SECUREAUTH

#Authentication #APISecurity #TokenBasedAuthentication #RefreshToken #WebDevelopment #Cybersecurity #BackendDevelopment

Top comments (0)