Sanity checking refresh token expiration

I have a site that users can log into, close, then re-open a day later, and be automatically silently logged in. This is not desired behavior, as the user should be required to enter their credentials again after a long period of inactivity. In an effort to create this behavior, I set the application’s id token expiration and refresh token lifetime to 60 seconds. I also set the audience api’s token expiration and token expiration for browser to 60 seconds. Alas, to no avail, as a user that logs in, closes the webpage, then returns after a long period still gets silently logged in.

Looking at the payload of the token, it’s easy to see that the expiration of the token is, in fact, a mere 60 seconds after the issuing of the token. This leads me to suspect the refresh token is to blame. The refresh token itself has a rotating behavior with a refresh token lifetime of 60 seconds (recommended for SPA applications), and a refresh token reuse interval of 0 seconds.

Any advice on forcing the user to log in again, even if that means disabling refresh tokens entirely, would be greatly appreciated.

Hi @cwaugh

This is the session, not the access or id token (or refresh token).

Go to your dashboard, open up the tenant settings, and look under the advanced tab for your session timeouts.


1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.