Session Lifetime Limits
Session lifetime limits determine how long the system should retain a login session. In Auth0, two settings can be configured for session lifetime:
Inactivity timeout: Timeframe after which a user's session will expire if they haven’t interacted with the Authorization Server. Will be superseded by system limits if over 3 days for self-service plans or 100 days for enterprise plans.
Require log in after: Timeframe after which a user will be required to log in again, regardless of their activity. Will be superseded by system limits if over 30 days for self-service plans or 365 days for enterprise plans.
These settings are configured on the tenant; you can configure them using either the Auth0 Dashboard or the Management API.
When a user performs a new standard login, it resets the login session. Here's an example:
You set the Inactivity timeout limit to 3 days and the Require log in after limit to 30 days.
A user logs in and your entered values are set for their session.
If the user is active within the three-day Inactivity timeout timeframe, the session lifetime is extended for another three days. As long as the user is active within the next three days, their session lifetime will be extended for another three days, until the Require log in after limit is reached. At this point, the user will be required to log in again.
If the user is inactive for three days, they will automatically be logged out.
While the user is logged in, you extend the existing session lifetime limits. The new settings will not take effect until the existing session ends, and the user logs in again.
While the user is logged in, you reduce the existing lifetime limits. The new settings will take effect immediately upon the user's next activity. This allows you to shorten session lifetimes for security purposes.
Application-specific logout URLs
There are two important things to consider when you use application-specific logout URLs:
You must send
client_idas a query parameter when calling the
/v2/logoutendpoint and the
returnToURL must be in the application’s list of allowed logout URLs.
This will end the Auth0 Session for the entire tenant - i.e. for all defined applications, not just the one that matches the
client_idsupplied. Passing the
client_idtells the /
logoutendpoint where to look for the logout URL white-list.
After the user logout occurs Auth0 will only redirect to a URL that is defined in this list.
If you redirect the user back to the application after logout and the application redirects to an identity provider that still has an authenticated session for that user, the user will be silently logged back into your application and it may appear that logout didn’t work. In these cases, we recommend that you have a specific logout landing page in your application so you can tell the user that they successfully logged out - and, if desired, you can also warn them that they may still be logged into their identity provider.
In the case where a user has not taken any actions that cause the Auth0 session to be updated, we recommend that you warn the user to choose to explicitly continue their session. The intent of this approach allows the session to go inactive if the user is no longer present but otherwise provides a means to trigger the silent token refresh so that they can continue their session without the need to be prompted again for credentials.
Inactivity Timer: Add a rolling timer to the React SDK wrapper that aligns with the maximum idle lifetime of the Auth0 session. Each time a token is returned to the application, reset the timer.
Timeout Modal: When the timer hits 60 seconds from expiration, a timeout modal should render requesting the user to logout or continue their session.
Continue the session: If the user chooses to continue their session, use the
getTokenSilently()method to request a new token without redirecting the user from the page they are currently interacting with.
Logging out: In the case, the user chooses to logout the
logout()method should be called to assure the Auth0 session is ended as well.
Idle Timeout: In the case that the idle timeout is reached no immediate action is necessary. To handle the fact that the user may still be active in another tab, the behavior should not be to log the user out.
Other options include updating the modal with a login button, using the window.onfocus event to trigger
getTokenSilently(), or redirecting the user to landing page.