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:
State: <ONLINE, NOT AUTHENTICATED>
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()
State: <ONLINE, AUTHENTICATED>
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).
State: <OFFLINE, AUTHENTICATED>
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.
State: <OFFLINE, NOT AUTHENTICATED>
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)