Can we authenticate into auth0 while being offline?

Can we authenticate (auth0 session layer) while being offline? Effectively I’d like to get to a state of auth0.isAuthenticated = true while being offline, provided that the user had a prior authenticated session.

This is an SPA PWA application using auth0-spa-js.

My application flow looks like this:


const auth0 = createAuth0({
    domain: auth0Domain,
    client_id: auth0ClientId,
    audience: auth0Audience,
    redirect_uri: window.location.origin,
    scope: 'openid email profile offline_access',

I recently added the scope, hoping that that would make the difference, but it doesn’t seem to.

Once auth0 settles (isLoaded=true, isAuthenticated=false) The (already existing) user logs in:

await loginWithRedirect()


Doing a page reload at this time allows me to “silently” get the JWT token by means of:

await getAccessTokenSilently()

Now, to test being offline, I disconnect my network cable (initally added a firewall rule, but that turned out to be too finicky).


I will now hit F5, causing a page reload. The createAuth0() function now takes a really long time, and then times out. Calling getAccessTokenSilently() after this fails as well.


I could save the user details of the user, and remain logged in into the application (basically the application session layer). This is an SPA, and all important security therefore sits in the backend; I don’t even need the token while being offline. However, I do would have to add some code that checks the auth0-state and re-authenticate with the auth0 session layer, as soon as it is online again, I am hoping to prevent that.

Not unsurmountable, but I feel that there may already be a solution for this. Is that so? Would love to hear how this, I recon fairly common case, is normally handled. Thanks!

I recognize that the issue might be here that it’s not safe to persist the access token. However, I only care about the access token while actually being online, not while offline, as it is only used to authorize actions on the backend (which I presume is offline as well anyway). (background: all user changes are stored locally while being offline, and synced later when back online)

Hey there!

Unfortunately I fear that it’s not possible the only usecase in which you can use Auth0 in an offline mode is purely for testing. Reason to that? What you just mentioned: security.

1 Like

It occurred to me that we can specify localStorage as the cacheLocation (normally this would be memory, and it seems that memory doesn’t survive a page refresh. This way you can still login while being offline.

This… seems to work… Or am I missing something here?

An localstorage entry is being created; key=

@@auth0spajs@@::8JdcGx...::https://redacted.redacted.tld::openid profile email


{"body":{"client_id":"8JdcGx...","access_token":"eyJhbGciOi...","scope":"openid profile email","expires_in":86400,"token_type":"Bearer","decodedToken":{"encoded":{"header":"eyJhbGciOi...","payload":"eyJnaXZ...","signature":"KXBeS9..."},"header":{"alg":"RS256","typ":"JWT","kid":"6xLgW..."},"claims":{"__raw":"eyJhbGciOi...","given_name":"Redacted","family_name":"Redacted","nickname":"Redacted","name":"Redacted","picture":"","locale":"en-GB","updated_at":"2023-06-22T...Z","email":"Redacted","email_verified":true,"iss":"","aud":"8JdcGx...","iat":16875...,"exp":16875...,"sub":"google-oauth2|111...","sid":"086C8...","nonce":"UUJ0M..."},"user":{"given_name":"Redacted","family_name":"Redacted","nickname":"Redacted","name":"Redacted","picture":"","locale":"en-GB","updated_at":"2023-06-22T...Z","email":"Redacted","email_verified":true,"sub":"google-oauth2|111..."}},"oauthTokenScope":"openid profile email","audience":"https://redacted.redacted.tld"},"expiresAt":1687565651}

Any comments on this?

On a side note:

While going through the createAuth0-options, I noticed that the default timeout for the HTTP fetch is 10 seconds, while authorize is 60 seconds. One would expect that if the http fetch fails, the authorize is going to fail as well, why wait longer for the authorize? Or is the fetch retried perhaps?