> ## Documentation Index
> Fetch the complete documentation index at: https://docs-staging-quickstart-revamp.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Describes limits a system will allow a session to last before termination.

# 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:

* **Idle Session Lifetime**: Timeframe after which a user's session will expire if their <Tooltip tip="Session Cookie: Entity that, when present, allows the user to be considered authenticated." cta="View Glossary" href="/docs/glossary?term=session+cookie">session cookie</Tooltip> hasn't interacted with the <Tooltip tip="Session Cookie: Entity that, when present, allows the user to be considered authenticated." cta="View Glossary" href="/docs/glossary?term=Authorization+Server">Authorization Server</Tooltip>. Will be superseded by system limits if over 3 days for self-service plans or 100 days for enterprise plans.
* **Maximum Session Lifetime**: 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](/docs/manage-users/sessions/configure-session-lifetime-settings) or the <Tooltip tip="Management API: A product to allow customers to perform administrative tasks." cta="View Glossary" href="/docs/glossary?term=Management+API">Management API</Tooltip>.

When a user performs a new standard login, it resets the login session. Here's an example:

1. You set the **Idle Session Lifetime** limit to 3 days and the **Require log in after** limit to 30 days.
2. A user logs in and your entered values are set for their session.

   1. If the user is active within the three-day **Idle Session Lifetime** 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 **Maximum Session Lifetime** limit is reached. At this point, the user will be required to log in again.
   2. If the user is inactive for three days, they will automatically be logged out.
3. 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.
4. 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_id` as a query parameter when calling the `/oidc/logout` endpoint and the `id_token_hint` URL 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_id` supplied. Passing the `client_id` tells the /`logout` endpoint 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 <Tooltip tip="Identity Provider (IdP): Service that stores and manages digital identities." cta="View Glossary" href="/docs/glossary?term=identity+provider">identity provider</Tooltip> 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.

## Learn more

* [Configure Session Lifetime Settings](/docs/manage-users/sessions/configure-session-lifetime-settings)
* [Update Access Token Lifetime](/docs/secure/tokens/access-tokens/update-access-token-lifetime)
* [Update ID Token Lifetime](/docs/secure/tokens/id-tokens/update-id-token-lifetime)
* [Check Login and Logout Issues](/docs/troubleshoot/authentication-issues/check-login-and-logout-issues)
* [Troubleshoot Invalid Token Errors](/docs/troubleshoot/basic-issues/invalid-token-errors)