Storing Auth0 tokens in session storage instead of local storage

Hi Team,

I am using auth0-spa-js in React JS. I am using gettokensilently method to get the token from Auth0 server and currently setting the cachelocation to local storage. Is there any way to tell Auth0 to store the token in session storage instead of local storage , so that I can maintain different users session in different browser tabs as part of my requirement.

Thanks in advance,

Hi @harigovind2295,

Currently, auth0-spa-js only supports caching tokens in memory or local storage: Token Storage

You may be able to maintain two user sessions in different tabs by setting sessions to non-persisting (Settings > Advanced):

And using memory instead of local storage in the app:

    scope="read:current_user update:current_user_metadata"
    <App />

Tokens stored in memory won’t be available in new tabs, and if the session is set to non-persisting, silent auth won’t log the same user in, so you should be able to log a different user in on the other tab.

1 Like

Hi @stephanie.chamblee ,

In my application, cacheLocation has been set to “localstorage” in Auth0Provider component.

And lot of logic has been written internally in application to read the data from localstorage. But now there is one requirement to get access token/ID token for other users for which I am using getAccessTokenSilently method in useAuth0 hooks.

const { user, logout, getAccessTokenSilently, getIdTokenClaims } = useAuth0();

But I don’t want the token which I am generating using getAccessTokenSilently method to be stored in localstorage but it does which I presume it picks cacheLocation settings from Auth0Provider component. Is there any way to override the cacheLocation in getAccessTokenSilently method or using the useAuth0 hooks.

Thanks in advance,

Hi @harigovind2295,

Unfortunately, if you require the Auth0Client to be configured with localStorage you won’t be able to maintain two user sessions in different tabs. You can use the ignoreCache in the getAccessTokenSilently (API docs), but there is not a similar option for getIdTokenClaims. For this use case, I believe you’d need to use memory for cacheLocation.

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.