Why Users Remain Login After the Inactivity Timeout

Problem Statement:

We set the Refresh Token Inactivity Expiration to 15 seconds in the applications setting. Why is our Web App still alive after 15 seconds?

Our current Login Session Management settings are (1) Non-Persistent Session. Inactivity timeout: 1 minute, and (2) Require login after: 60 minutes. With this setting, our 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 your application can still have an Auth0 session cookie that says the user is still logged in.

In your tenant setting under the Advanced tab, you can 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, Auth0 session, and an IdP session. This article explains the session layers and how to control the duration of the user’s local application session.

The reason for users remaining logged in after the inactivity timeout is because the application session is not being 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.

References:

1 Like