Hi,
I have set
Inactivity timeout to 6 minutes
Token Expiration For Browser Flows (Seconds) to 300 sec
Token Expiration (Seconds) to 300 sec
and I have Refresh Token Rotation enabled.
For testing purposes I have used smaller values.
In my front end app, I am using auth0-spa-js module and I have logic to refresh access token 30 sec before its expiration.
I was expecting
when the access token is refreshed 30 sec before its expiration(using getTokenSilently), I would receive a new set of access and refresh tokens and Auth0 session cookie life time would be extended by 6 minutes.
Actual behavior was, I am receiving new set of tokens, but I think Auth0 session cookie life time is not extended, because when I try to do page refresh 2 minute after receiving new set of tokens, I am redirected to Auth0 login page.
Does calling getTokenSilently extend Auth0 session cookie life time as well?
What should I do to extend Auth0 session cookie life time, so that, page refresh works?
The Refresh Token is designed to be independent of the user’s session, so I don’t think it will modify the current session as it calls the token endpoint directly without a cookie.
When you refresh the page, I suspect it is wiping the browser memory storing the Refresh Token (the SDK’s default location for storing tokens), so your app falls back to making a silent authentication within an Iframe, which unlike Refresh Tokens is reliant on the session being valid (and the Auth0 cookie being available).
If you want to provide persistence across page refreshes and tabs, you would need to configure the Auth0Client to use ‘localstorage’ - however, this is less secure as mentioned in the documentation linked above.
If you want to keep the app in line with the Auth0 session, I would recommend turning off refresh tokens as they do not require a session to operate, and using an Access Token lifetime that is shorter than your tenant’s session inactivity lifetime to ensure the session does not expire when you go to fetch new tokens.
If you wanted to fetch new tokens before the current one expires still, you would need to enable the ignoreCache option on the getTokenSilently call, otherwise, the SDK will not make a call to Auth0 if the currently stored token is still valid.
I tried turning off refresh tokens and using access token lifetime shorter than session inactivity lifetime. It works in normal chrome tabs, but in incognito, when I try to fetch a new token before the old one expires it throws a ‘login required’ error. I think it’s because, by default, 3rd party cookies are disabled in incognito.
So, the only option that works both in normal and incognito windows is to use localstorage to store tokens?
Yes, silent authentication is reliant on the Auth0 session cookie being present in the requests sent to Auth0, if the browser blocks them then Auth0 will not recognise the user as having a session and say a login is required. Chrome can be set to allow 3rd party cookies in incognito mode, but end-user browsers may be dropping 3rd party cookies in either mode - which you would have little control over in most scenarios.
If you were to set up a Custom Domain for your tenant you could avoid cookies being treated as 3rd party by browsers and dropped from requests, by having your App and Auth0 tenant share a common parent domain, but this does require a paid plan, so unfortunately not an option if you are on a free plan.
So if you cannot use cookies for silent authentication due to not being able to use a Custom Domain, and require the user to remain logged in to Auth0 between page refreshes and browser tabs, you would need to use localstorage and Rotating Refresh Tokens, and set your Refresh Token expiry settings to suitable values for your security needs so the user has to log in again when you want them to.