Expired token was received from getTokenSilently

[tom-zeit]

Description

Expired token was received from getTokenSilently.

Reproduction

1. User logins or already logged in
2. The user hasn't done any actions for more than 24 hours
3. After more than 24 hours, the user interacts with the app, and an API call is made
4. The token is fetched using getTokenSilently and is set on the backend request header
5. the backend fails the request with a token expired exception

Analysing auth0 logs, I see that the user hasn't made any calls to auth0 server with "Success Silent Auth" before calling the backend.
This means that an expired token was returned from the cache.

Looking on the implementation of the cache, I see that it uses setTimeout to invalidate the cache entries. This is not reliable in case that the user computer was in sleep mode:
https://stackoverflow.com/questions/6346849/what-happens-to-settimeout-when-the-computer-goes-to-sleep

I think that a better cache mechanism would be to check the cache entry validity on get, and if the entry has expired, then remove it from the cache at this point.

Environment

• Version of this library used: 1.6.0
• Other relevant versions (language, server software, OS, browser): User was on macOS with Chrome 79

[tom-zeit]

One other question, in theory, getTokenSilently should always work unless the user refreshed the page? From security perspective, a user can leave the browser open, and get a valid token from getTokenSilently forever?

[stevehobbsdev]

@tom-zeit Thanks for raising this. I agree with your assessment that the cache should be invalidated on read as well. We're currently working on rewriting the cache for the 1.7 Beta, and so this change will more than likely happen there.

From security perspective, a user can leave the browser open, and get a valid token from getTokenSilently forever?

This behaviour relies on the auth0 session cookie from Auth0 server. So you can leave the browser open and get valid tokens repeatedly until the Auth0 session expires, after which the user will have to proceed through the interactive login flow to renew their session.

[tom-zeit]

@tom-zeit Thanks for raising this. I agree with your assessment that the cache should be invalidated on read as well. We're currently working on rewriting the cache for the 1.7 Beta, and so this change will more than likely happen there.

From security perspective, a user can leave the browser open, and get a valid token from getTokenSilently forever?

This behaviour relies on the auth0 session cookie from Auth0 server. So you can leave the browser open and get valid tokens repeatedly until the Auth0 session expires, after which the user will have to proceed through the interactive login flow to renew their session.

@stevehobbsdev - Thanks, looking forward to this fix, any ETA on that? It's a major issue for us in production.

Regarding the second part - when you say that the user have to proceed through the interactive login flow, does it mean that we should explicitly trigger that flow? or does it happen automatically when calling getTokenSilently?
From the API documentation, I understand that every call to getTokenSilently should get a valid token, and I want to make sure that we don't have to actively redirect the user to the login flow in some cases.

[stevehobbsdev]

@tom-zeit Feels like a small change, I should be able to get this in this week.

From the API documentation, I understand that every call to getTokenSilently should get a valid token

Unfortunately what we're dealing with here is not an API call. To get a new token, we call the /authorize endpoint from a hidden iframe with a prompt=none flag, retrieve a new code, and then call the /token endpoint to get a new access token. The first part is key because it relies on the auth0 cookie to work. That session will expire after a maximum time of 30 days regardless of activity (this can be configured in your tenant settings). If the session does expire, you should start seeing a login_required error from getTokenSilently, which you can react to and put the user through a new interactive login flow.

Now, I know that's not ideal given your use case and we are working on some new tools to help you in this case, but they won't be ready in the short term.

[stevehobbsdev]

@tom-zeit auth0/[email protected] now has this change to the cache where it is invalidated on read instead of using setTimeout. Please can you try working with that version, and feel free to continue/re-open the discussion if you are having further issues.