In persistent sessions, users close a browser, but retain the session when re-opening the browser on the same device. To enhance the user experience and provide more secure access, non-persistent sessions invalidate a session cookie when the browser is closed.
In some cases, non-persistent sessions cannot be enforced by tenant settings. Examples include:
The user has a session restore setting on the browser enabled; restoring the session also restores the session cookie.
The user closes a tab but not the browser window; the session cookie is not cleared until the session ends based on Idle or Absolute Expiration.
Sessions consist of a cookie on the browser and a session record on the server. In non-persistent sessions, cookies are not persisted, and a tenant timeout is set, so users don’t have to manually log out of a device.
Session lifetime determines how long the system should keep the login session and is configured per tenant. The Absolute Expiration of a session is defined when the session is created. You can enable non-persisted settings for user sessions, or allow the session to continue even if the browser is closed. You can adjust the Absolute Expiration and non-persisted settings in the Dashboard or the Management API. To learn more, read Configure Session Lifetime Settings.
The Auth0 platform uses three types of cookies: session, Multi-Factor Authentication, and device. All of these change to non-persistent once your Auth0 tenant is configured. The tenant timeout triggers the session expiration.
When non-persistent sessions are enabled, the following cookies will be issued as session cookies when interacting with the authorization server:
To learn more about cookies, read Authentication API Cookies.
You can configure your tenant to handle sessions in one of two ways:
Persistent Mode: session cookies persist when the browser is closed.
Non-Persistent Mode: session cookies do not persist. The browser retains session cookies until the browsing session is over. To learn more, read HTTP State Management Mechanism on IETF Datatracker.
|Inactivity timeout||Timeframe (in minutes) 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 4,320 minutes (3 days) for Developer or Developer Pro or 144,000 minutes (100 days) for enterprise plans.|
|Require log in after||Timeframe (in minutes) after which a user will be required to log in again, regardless of their activity. Will be superseded by system limits if over 43,200 minutes (30 days) for Developer or Developer Pro or 525,600 minutes (365 days) for enterprise plans.|
To configure these settings in the Dashboard:
Go to Dashboard > Tenant Settings, and select the Advanced view.
Scroll to the Log In Session Management section, locate Inactivity timeout and Require log in after, enter the desired settings, and select Save.
You can use the Management API to enable non-persistent sessions as well as set values for session lifetime, idle sessions lifetime, and properties for sessions cookies. To learn more, review the Management API Tenant Update endpoint.