Problem Statement
In this scenario, the Refresh Token Inactivity Expiration has been set to 15 seconds in the Applications setting. However, a Web App appears to remain active after the 15-second timeout window has expired.
Here are the current Login Session Management settings:
- Non-Persistent Session. Inactivity timeout: 1 minute
- Require login after: 60 minutes
With this setting, the app remains logged in after 1 minute of inactivity or after the app is closed and then reopened.
Solution
Session lifetime and Refresh Token lifetime are two separate things. The refresh token can expire, and the application can still have an Auth0 session cookie that says the user is still logged in.
In Tenant Settings, under the Advanced tab, there is an option to force users to re-authenticate to start a new session by configuring (1) the Inactivity Timeout and (2) the Require Login After lifetimes.
Sessions can be created on three different layers:
- an application session,
- an Auth0 session
- an IdP session.
This article explains the session layers and how to control the user’s local application session duration.
Users remain logged in after the inactivity timeout because the application session is not cleared when the Auth0 session expires. As for the Non-Persistent sessions remaining after closing and reopening the application, there are a few cases where 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.