Cache always relies on the access_token lifetime, never on the id_token lifetime
cemercier opened this issue · comments
Problem
Hello, I run into an issue when integrating my application with the react auth0 sdk. We are using the id_token to authenticate our calls from our spa to our backend (we don't rely on auth0 for authorization so we don't need to use the access_token). I set my id_token lifetime to a few minutes, however the getTokenSilently function does not try to refresh it because the cache seems to be based on the access_token lifetime, given by the expires_in in the response of the /oauth/token call (24h by default):
This results in 401 from my backend.
Ideal solution
It would be handy to be able to configure the cache so the it can be based either on the access_token lifetime or the id_token lifetime. It should be possible since the id_token contains the timestamp at which it expires (exp).
Work-arounds
For now we disabled the cache. We are considering also the idea to implement our own cache system, based on the id_token lifetime.
Thanks for reaching out, it's by design in v2 that we do not consider the id_token's expiration so there is no issue, but it's working as expected.
On top of that, using the id_token the way you are is not what they are design for and not something we intend to support with this SDK.
We are considering also the idea to implement our own cache system, based on the id_token lifetime.
If the above behavior is exactly what you believe you want to be using, then I would recommend solving this yourself using your own cache or whatever solution works for you, I would even ask myself if using this SDK is something you want to begin with.
Anyway, our SDK is not a place to handle such use-case specific logic.
Thanks for your quick answer. Can I ask you what's the id_token expiration date's for ? Is it handled by the sdk in some ways ?
An id token is used to exchange user information, and we can only exchange it as long as it expires. The expires claim here only affects the moment we can accept the id token, but we shouldnt check it anymore after having accepted it.
You are sending it with every request, means you are constabtly reading it, which is not what id tokens are for. Instead they are used to read it once in your frontend application, and then we know who the user is until they logout. The id token expiration should not determine the session duration in a SPA.
If you want that, you can but will need to roll your own as mentioned.
But long story short, id tokens should never be sent to An API, see https://auth0.com/docs/secure/tokens/id-tokens
ID Tokens should never be used to obtain direct access to APIs or to make authorization decisions
If you decide to do things differently, that's not something we can offer through our SDK.
Understood, I have a very last question for you before closing this issue, to be sure of how the SDK is working: what is supposed to happend when calling the getTokenSilently function with an expired refresh token?
I would expect the SDK to get a new token, but instead I get a refresh call that falls in 403. I think this problem is again related to the fact I'm using the id_token instead of the access_token, can you please confirm this ?
A refresh token is intended to refresh the access_token. We do know it will also refresh the id_token, but that's not the main reason. You should have no reason to "refresh the id token" purely in terms of expiration.
When u call getTokenSilently, and you use refresh tokens it will try and use the refresh token. If that fails, and useRefreshTokenFallback is set to true, it will try using iframes as a fallback. If it's set to false, it will throw an error.
That said, it's not failing because the fact that you use the id_token, it should still work and refresh the id token and access token when the access token is expired. If it fails, it might mean that the refresh token is expired.
Ok ,thank you for your patience ! I'm closing this.