403 Errors from Refresh Token Calls

Knowledge Articles
1

Last Updated: Dec 5, 2024

Overview

The dashboard log is having many 403 errors when calling /token endpoint for refresh tokens.

Applies To

  • 403 Error
  • Refresh Token
  • API Calls

Solution

This document contains the important configuration relevant to the 403 messages from refresh token calls.

Please check the absolute and inactivity lifetime values based on the doc above.

The default value for absolute lifetime is 30 days. This value might be different depending on the desired behavior.

To better understand this value, imagine a user logging into an application. The user will get an Access Token, which is shorter-lived than the refresh token. This access token will have an expiration time. Check this document to find the expiration time of the access tokens.

So, normally, this access token expiration is too short for a good user experience since it will ask the user to log in more often. This is where Refresh Tokens come into play. Refresh tokens basically permit having an access token with a short expiration time. In other words, use these refresh tokens to get new access tokens without user interaction. This permits having a good user experience without compromising the security of having a long-live access token.

Going more technical, the application/SDK is doing a getAccessTokenSilently call, something close to this:

const auth0 = await createAuth0Client({
    domain: '<your Auth0 domain>',
    client_id: '<your Auth0 client ID>',
    cacheLocation: 'localstorage',
    useRefreshTokens: true
    });
    
    // Logging-in will automatically request the offline_access scope
    // and store the resulting refresh token
    auth0.loginWithRedirect();
    
    // Silently refreshing the access token will use the /token endpoint
    // with ‘refresh_token’ grant and the refresh token from the cache
    await auth0.getTokenSilently();

With refresh tokens, there will be localstorage in cache, but when needed (the previous access token is expired and a new one is needed, remember they last one hour in this case). The getTokenSilently() call does automatically call the /token endpoint in order to refresh the token. Read more about how this works in this document.

Now, returning to the original topic, the absolute lifetime is for how long is possible to keep calling these “getTokenSilently” method and actually getting a valid access_token back.

Imagine that the website is opened for a client, and they’ve left the browser open for longer than the absolute lifetime expiration or they’ve been inactive for longer than the inactivity period. These calls to refresh the token will return in a 403 since the expiration time has passed, and they are no longer able to retrieve access tokens.

We would suggest then looking at the implementation code and checking exactly when this refresh token calls are invoked. Depending on the SDK, it may be a bit different but usually is a “getTokenSilently” or “getAccessTokenSilently” call. Check for these calls, and check what actually happens in the application flow when these return a 403. Is the user redirected to the login page or does the site keep trying to generate tokens?

The first 403 received is completely normal and not an issue. It is just pointing out that they will not get a refresh token anymore. However, it is true, that if the application is trying so many times, it is pointless and just adds noise to the dashboard logs.

Also, the more user activity in the application, the more error logs will be received. It’s common to leave a site open and come back to it hours later or even days later. This mechanism just allows them to not have to re-login.