I’m writing a SPA using auth0-react 1.11. Either I’m doing something wrong or there is an issue with token caching. It feels like I’m following all recommended practices.
I call getAccessTokenSilently before every call to our API that expects a valid accessToken. And for every single endpoint there’s a new token that it retrieves from /authorize. If I decode the tokens the only difference is that the timestamps have changed.
We are setting an audience but it’s centrally set in the Auth0Provider and never changes. Of course ignoreCache is not on. Changing the storage between memory and localStorage has no effect. Changing browser or moving over to refresh tokens has no effect.
Is this a side-effect of setting the audience in Auth0Provider? What can I do to reduce the number of calls to your servers (in order to have better access times and prevent throttling on your end)?
That is indeed a weird situation; the likely most definitive action to find the root cause would be to debug step by step and try to see if you can get any hints as to why the SDK code is choosing to obtain a new token.
Another quick check is to configure to use Web Storage for caching and then manually check that after obtaining an access token you do see it in local storage using the browser dev tools.
Thank you so much for these pointers. I stored the tokens in localStorage for debugging and compared the timestamps. While the access token itself was not to be expire for the set amount of time, it was encapsulated in what looks like an id_token that was set to expire after a very short amount of time (because that was mentioned as a workaround for Safari’s ITP technology). So the expires value was always correct but the expiresAt that is stored with the caching but not encoded into the token asked for a fresh cache entry which triggered requesting a fresh token.
For future reference: if anyone runs into the same problem make sure that your ID Token Expiration is set to a reasonable value. It’s set per application not per API.