Refresh Token Mechanism with Axios Interceptors in React Native

Handle token expiry and maintain secure, seamless user sessions

Ever opened a site only to find yourself randomly logged out? Annoying, right? Users don’t care about refresh tokens or Axios interceptors — they just want things to work smoothly.

But as developers, it’s our job to make sure that a seamless login experience never breaks. Behind the scenes, that experience is powered by access tokens and refresh tokens.

In OAuth2, access tokens are short-lived for security, while refresh tokens help us silently generate new access tokens without forcing users to log in again. This is what keeps long-running sessions active — especially in mobile apps.

To make this work properly on the client side, a reliable refresh token mechanism is crucial. And Axios interceptors are one of the best ways to handle token expiration gracefully.

In this post, we’ll walk through how to handle refresh tokens with Axios interceptors — the right way.

What is the Refresh token mechanism?

A Refresh token works like a secret key to renew app access. When a user logs in, they get an access token with a short lifespan and a longer-lasting refresh token. The refresh token lets the user get a new access token after expiry, ensuring smooth access without logging in again.

This process, known as the refresh token mechanism, prevents users from logging out and logging in again to access app data. Instead, it renews the access token using the refresh token when the access token expires.

Let’s explore the refresh token mechanism in detail using Axios interceptors!

Implementing Refresh Token Mechanism with Axios Interceptors

Axios interceptors are used for automatic access token renewal on expiration, ensuring a smoother user experience with uninterrupted API calls.

Let’s break it down with a real-world scenario to understand it better:

Imagine you have a feed screen in your application where multiple API calls are made. If an access token expires during one of these API calls, the server responds with a 401 (Unauthorized) error. Without a token-refresh mechanism, users would suddenly get errors or be logged out. But with Axios interceptors, we can silently refresh the token, retry the failed request, and continue seamlessly — the user won’t even notice.

Handling API Requests via Request Interceptor

When an API call is about to be made, the Axios Request Interceptor executes before the request is actually sent to the server. Its primary responsibility is to automatically attach the latest valid access token to the Authorization header of every request, without requiring the developer to add it in each API call manually. Here is the code example for reference:

[embed]

Handling Token Expiry & Refresh Flow (Response Interceptor)

Once we attach access tokens to every outgoing API request using the Request Interceptor, the next step is handling cases where the access token has expired or is invalid.

Instead of immediately redirecting the user to login, we try to silently refresh the token and retry the failed requests automatically — providing a seamless user experience.

This entire mechanism is achieved using the Axios Response Interceptor combined with a refresh token handler, a queue, and a status flag.

Preparing the Helpers

Before diving into the Response Interceptor, we set up two key utilities:

[embed]

• isRefreshing → Prevents multiple refresh token API calls when many requests fail at once.
• failedReqQueue → Temporarily stores failed requests until a new token becomes available.

Processing the Queue

[embed]

The processQueue function manages a queue (failedReqQueue) of requests that failed due to an expired token. It either rejects each request with an error (error) encountered during a token refresh or resolves them with a new token (freshToken) after a successful refresh. After processing, the queue is cleared to handle future requests.

Handling Token Expiry via Response Interceptor

[embed]

Inside the response interceptor, if the API call succeeds, we simply return the response as it is. But if we receive a 401 status code, it means the access token has expired or is invalid. Before retrying, we also verify the _retry flag to ensure the same request is not executed again in a loop.

Handling If Token Refresh Already In Progress

[embed]

• If a token refresh is already in progress, this block of code adds the request to a queue to be retried later.
• When the token refresh completes, the original request is updated with the new token and retried using axios(originalRequest).

Start Refresh Flow

If refresh is not already running, we begin:

[embed]

This block of code will execute in the first go. The originalRequest is marked with _retry = true to indicate it has been retried, preventing infinite retry loops.

The isRefreshing flag is set to true to indicate that a token refresh process is currently in progress.

[embed]

Then let’s come to the return block. I have used Redux to manage the mechanism; you can use your method according to your code structure.

[embed]

Fetch the refresh token from your state management and use it to dispatch an action that refreshes the access token.

[embed]

Then the process of subscribing to the Redux Store comes into the picture because we have to handle the result of the token refresh action. So we subscribe to the Redux store. This allows us to react to changes in the store, such as the result of the token refresh action.

[embed]

First of all, we check if refreshTokenError.message is undefined or null to determine if the token refresh was successful; otherwise, we handle the error.

Handling Successful Token Refresh

When the token refresh is successful, the code retrieves the updated access token (freshAccessToken) from the Redux store. This token is then used to update the Authorization header of the originalRequest.

Afterward, we proceed to handle the queue of pending requests by invoking the processQueue function with null and freshAccessToken. This involves iterating through the failedReqQueue and retrying each request with the updated token (freshAccessToken).

Then the flag isRefreshing is set to false to indicate that the token refresh process is complete.

The unsubscribe function is called to stop listening for further updates from the Redux store. This is important to prevent memory leaks and ensure that the subscription is only active during the token refresh process.

Handling Token Refresh Errors

In the else block, if there’s an error during token refresh, we handle it by processing the error in refreshTokenError from Redux. We then manage pending requests using processQueue, rejecting each with refreshTokenError.

Afterward, we reset isRefreshing to false to conclude the refresh attempt, and unsubscribe from further Redux updates for efficiency. This ensures our application manages token refresh errors effectively and maintains smooth operation.

Benefits of Using a Refresh Token Mechanism with Axios Interceptors (Why This Matters)

Seamless & Uninterrupted User Experience — The user never notices a token expiry. They can work for hours without being suddenly logged out while performing an action. This is critical for applications like dashboards, text editors, or admin panels where long sessions are common.

Efficient Parallel-Request Handling via processQueue— When multiple API calls fail due to token expiry, your implementation queues them using failedReqQueue and processes them only after the token is refreshed, preventing failures and duplicate calls.

Enhanced Security with Short-Lived Access Tokens — Short-lived access tokens reduce exposure, while refresh tokens securely extend user sessions.

Prevents Multiple Refresh Calls (isRefreshing) – Only one refresh token request is sent, even if several APIs return 401 at the same time.

Conclusion

Handling refresh tokens with Axios interceptors is a small background task, but it can have a huge impact. When implemented correctly, users stay logged in smoothly. No interruptions. No forced re-logins.

It also plays a big role in app security. Refreshing tokens isn’t enough — you must store them safely and rotate them properly. That’s where best practices matter.

Patterns like token refresh, request queuing, and secure session management help create mobile applications that users can rely on every day. These are the same engineering principles Simform applies while building scalable React Native applications with secure, production-ready architectures.

If Axios interceptors are new to you, check out my **previous blog** first. It will help you understand how they work and why they’re important in this setup. The goal is simple: stay proactive, not reactive. Build it right now, avoid bigger issues later. Happy users, safer app.

If you’d like to explore the full implementation, check out the GitHub Repository

For more updates on the latest tools and technologies, follow the Simform Engineering blog.

Follow Us: X | LinkedIn