`getTokenSilently` throws `login_required` error when waking up computer

For context: I am using auth0 in a vue app with "@auth0/auth0-spa-js": "^1.12.0" with local storage cache and rotating refresh tokens. The refresh tokens are configured to be valid for a week and the access tokens for a day.

In the scenario below I made sure to log out, clear cookies and local storage, and log in anew, starting a new session with fresh tokens which should be valid for the times mentioned above.

When I put the computer to sleep without closing the tab, wake the computer up a few minutes later, the first call to getTokenSilently throws the login_required error instead of returning the cached access token which should still be valid, or getting a new access token (and rotating the refresh token) using the cached refresh token (which also should still be valid).
When I keep the tab open and the computer running, the access tokens are successfully exchanged when calling getTokenSilently, there’s no exception.

Why does getTokenSilently behave different when I wake the computer up compared to keeping it running?

Enabling “Allow Offline Access” in the API seems to resolve the issue. I’d like to better understand what the “Allow Offline Access” switch does and why I need to enable it.

According to auth0-spa.js documentation, auth0-spa-js always requests the offline_access scope when using refresh tokens.

The API documentation states:

Allow Offline Access: When this is enabled, Auth0 will allow applications to ask for Refresh Tokens for your API.

This sentence sounds to me as if actually this would always be required when using rotating refresh tokens. Or does the automatic token rotation using getTokenSilently not count as such an “ask for Refresh Tokens”? And why is the switch called “Allow Offline Access”, but the switch description doesn’t seem to reference network conditions?

Then there’s this section on token best practises:

If you limit offline access to your API, a safeguard configured via the Allow Offline Access switch on the API Settings, Auth0 will not return a Refresh Token for the API (even if you include the offline_access scope in your request).

Just as a reminder: auth0-spa adds this scope automatically. And tokens are anyway returned to the client and replaced regularly on the client’s demand for a new access token. Which leads me to ask: Does the “Allow Offline Access” switch have additional security implications?

I’m very thankful for any insight on how getTokenSilently and the API “Allow Offline Access” switch work!

Hi @b_beb,

Welcome to the Community!

I would be surprised to find this issue related directly to the SDK. It sounds more like a browser issue.

I’d like to try and recreate this. Can you tell me a few things first?

  • What browser/s does this occur with (or what have you tried)?
  • Have you tried an incognito or private browsing window?

The offline access scope is essentially a refresh token scope. If you add it in the request then you are requesting a refresh token be returned. Whether or not you will be issued a refresh token is dependent on if you have allowed offline access in your application.

Refresh tokens come with added security considerations because of their long lived nature and their intended use of requesting tokens without user credentials. Take a look at our docs for more info. If you have specific questions about security scenarios let me know and we can dig into them.

@dan.woda Thank you for your help! I fear I didn’t understand your response and need additional clarification. Sorry!

The offline access scope is essentially a refresh token scope. If you add it in the request then you are requesting a refresh token be returned. Whether or not you will be issued a refresh token is dependent on if you have allowed offline access in your application.

I still don’t get (whether)the(re is a) difference between the refresh token returned to the client when using rotating refresh tokens and the refresh tokens returned when the offline access scope is enabled. Could you answer me with a “yes” or “no” on the following question:
Is offline access scope required when using rotating refresh tokens? Or put differently: Will rotating refresh tokens work properly without offline access scope enabled?

Refresh tokens come with added security considerations because of their long lived nature and their intended use of requesting tokens without user credentials.

This comes back to the same question I asked above: when I have rotating refresh tokens enabled, do I assume correctly that I’m already using refresh tokens in my client? Because if so, then I fail to understand why enabling offline access scope would have additional security implications, given that my clients already receive refresh tokens from auth0. Could you clarify this?

Thanks in advance for helping to lift my confusion.
I’ll respond soon with information to help debug the getTokenSilently case when the computer awakes.

Update: It seems that my earlier testing was flawed. When I disable the offline access scope and shorten access token validity time to 5min, getTokenSilently returns the same access token for the first 4min, before it throws the Login required error reliably every 5th min (context: this is on an http localhost). My conclusion is that enabling rotating refresh tokens is not enough to actually use refresh tokens. Offline access scope needs to be enabled before sessions can survive past the duration of a single access token without a redirect / popup opening the login auth endpoint. This characteristic has nothing to do with whether the client is offline or online. Can you confirm?

In another turn of events, I’m no longer able to reproduce the situation:

Why does getTokenSilently behave different when I wake the computer up compared to keeping it running?

I would be surprised to find this issue related directly to the SDK. It sounds more like a browser issue.
I’d like to try and recreate this.

Yes

Simply enabling it does not mean you are requesting RRTs. You must request them using the offline access scope.

I’m not sure what you mean here.

Thanks for the last response, it answered all my questions.

From my perspective as user of auth0, the documentation is incomplete, which confused me and caused me to spend a lot of (your) time on answering my questions.
I’m noting mismatches between my expectations and the current state down here so that you can decide to take action: