Inactivity timeout is not respected when cacheLocation is localStorage

Describe the problem When using localStorage and refresh tokens, inactivity timeout/ “require login after” (set in auth0 tenant settings -> advanced) does not cause auth0.isAuthenticated() to return false. The documentation around inactivity logouts is badly lacking, both for this SDK as well as on the auth0 doc pages. For example, I have no idea how the inactivity timeout is actually enforced (i assume via the expiration date on the auth0.isAuthenticated cookie?)

What was the expected behavior? When the inactivity timeout is reached, auth0.isAuthenticated() should return false. Or there should be some other documented means of checking if the timeout has been reached in order to redirect user to login page.
Access tokens should also be invalidated. The mechanism of inactivity timeout should also be documented somewhere (is it looking at the cookie expiration date? I have no idea because I couldn’t find docs)

Reproduction Set “inactivity timeout” and “require login after” to one minute in the auth0 dashboard for your tenant. Configure library with options { cacheLocation: ‘localstorage’, useRefreshTokens: true, …otherOptions } Add some arbitrary code that checks the return value of auth0.isAuthenticated(), for example:

 setInterval(() => {
    check();
  }, 30000);
}

async function check() {
  const auth0 = await configureClient();
  const isAuthed = await auth0.isAuthenticated();
  if (!isAuthed) {
    sessionLogout();
  }
}

Log in with any account. Wait more than one minute auth0.isAuthenticated() continues to return true

Rerun the same configuration, but with cacheLocation: memory auth0.isAuthenticated() returns false, as expected

Environment Using “@auth0/auth0-spa-js”: “^1.13.3” in a react application. Tested in a stable version of Chrome

[nicosabena]

Auth0-spa-js, when you do getTokenSilently(), will try the refresh token flow first and if it doesn’t work then it will try to use the browser session (i.e. the session cookie) doing a fallback silent authentication request. This silent authentication request might fail because of a browser blocking the cookie in the request, but could also work well (and, in most scenarios, you’d want this to work, to spare the user from having to authenticate again). If that fails, the application might want to try an interactive authentication (with either a full redirection or a popup) and if the browser session is still valid then the user won’t be prompted to authenticate again. Which, again, is what you’d want under normal circumstances. If your use case require the user to re-authenticate after a period of inactivity, then you’ll need to coordinate the refresh token lifetime with the session lifetime. Otherwise the session will work as a fallback even when the refresh token is no longer valid.

Does that make sense?

[oneillsp96]

Thanks for the quick responses. Overall I’m really enjoying the new SDK, and the fact that it handles refresh token rotation automatically is a huge benefit.