Configure Session Expiry for Enterprise Connections (IPSIE)

Session Expiry is supported for Okta and OIDC Enterprise connections and is not available for Microsoft Entra ID (Azure AD) connections. Microsoft does not include the session_expiry claim in Entra ID Tokens.

Auth0 supports the session_expiry claim based on the Interoperability Profile for Secure Identity in the Enterprise (IPSIE) standard for Okta and OIDC Enterprise connections. When enabled, Auth0 captures the session_expiry (represented in seconds as a Unix timestamp) from the upstream Identity Provider (IdP) and includes it in the ID Token issued to your application. Auth0 consumes the session_expiry claim and synchronizes the local Auth0 session with the upstream IdP’s session lifecycle. This ensures when a user’s session expires at the Enterprise IdP, their Auth0 session also terminates.

The customer is responsible for processing the received session_expiry claim and to terminate and manage user sessions in their applications.

Before you start

Before enabling session expiry enforcement:

You must have an existing Okta or OIDC Enterprise connection.
The upstream identity provider must emit a session_expiry claim in its ID Token.

How it works

When a user authenticates through a session_expiry enabled Enterprise connection, Auth0:

Captures the session_expiry claim from the upstream IdP’s ID Token.
Calculates session expiration by evaluating specific parameters and sets the final Auth0 session’s expiration to the minimum (earliest) value of the following factors:
- The IdP session_expiry claim: The absolute timestamp in an ID Token from the upstream Identity Provider.
- Your Auth0 tenant’s default Absolute Expiration setting: The session lifetime limit you configure in Auth0 Dashboard or Management API. To learn more, read Configure Session Lifetime Settings.
- Auth0 Actions [setExpiresAt]: Any custom expiration timestamp programmatically set during the login transaction with the Post-Login Action api.session.setExpiresAt() method.
Uses a Post-Login Action you configure during enablement to pass the final evaluated session expiration to your application by injecting it as a custom claim into the Auth0-issued ID Token.

The session_expiry claim is a UNIX timestamp in seconds representing the absolute expiration limit for the user’s session:

{
  "iss": "https://YOUR_DOMAIN.auth0.com/",
  "aud": "YOUR_CLIENT_ID",
  "sub": "oidc|username@domain.com",
  "iat": 1748534400,
  "exp": 1748538000,
  "session_expiry": 1748566800
}

Claim	What it represents	Scope
`exp`	ID Token lifetime (typically minutes)	Token validation
`session_expiry`	Absolute expiration (seconds)	Session management

The session_expiry claim is not a replacement for exp. The ID Token’s own exp remains short-lived and unchanged. session_expiry is a session-level limit included with the token claims. session_expiry is fixed at login. It is set once when the user authenticates and is not updated when tokens are refreshed. A user already logged in before this feature is enabled will not have session_expiry on their existing session; the claim only appears after their next login.

This feature addresses scheduled session expiry only. For real-time session revocation, like when a user is off-boarded mid-session, we recommend you use Back-Channel Logout.

Enable session expiry enforcement

Configure session expiry enforcement on your Enterprise connection using the Auth0 Dashboard or Management API.

Auth0 Dashboard
Management API

Navigate to Auth0 Dashboard > Authentication > Enterprise in the Auth0 Dashboard.
Find the Okta or OpenID Connect Enterprise connection and select Browse.
Choose the connection you want to configure.
Under Settings, enable Use ID Token for Session Expiry.
Select Save.

To use the Management API, you need a Management API access token with update:connections scope.Make a PATCH request to the Update a connection endpoint:

PATCH https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID
Content-Type: application/json
Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN

{
  "options": {
    "id_token_session_expiry_supported": true
  }
}

Replace the placeholder values:

YOUR_DOMAIN: Your Auth0 tenant domain. Example: travel0.us.auth0.com.
YOUR_CONNECTION_ID: The ID of your Okta or OIDC Enterprise connection.
YOUR_MANAGEMENT_API_TOKEN: A Management API token with update:connections scope.

If you PATCH the options parameter, the entire options object is overridden. Ensure all existing properties are included when you PATCH options.

Send session expiration to your application

While Auth0 uses the calculated session expiration to manage its own session layer, your downstream applications may also need to know this absolute expiration time to enforce local session limits. Configure a Post-Login Action to inject the final, evaluated session expiration in an Auth0-issued ID Token and pass the token to your application.

Auth0 Dashboard
Management API

Navigate to Auth0 Dashboard > Actions > Library in the Auth0 Dashboard and select Build Custom Action.
Enter a name for the Action, select Login / Post Login as the trigger, and select Create.
Add the following code to your Action:

exports.onExecutePostLogin = async (event, api) => {
  // Check if a session expiration has been established
  if (event.session?.expires_at) {
    // Convert the ISO string date to a Date object
    const exp_date = new Date(event.session.expires_at);
    // Set the session_expiry custom claim as a Unix timestamp (seconds)
    api.idToken.setCustomClaim('session_expiry', Math.floor((exp_date.getTime()) / 1000));
  }
};

Under the Test panel, select Run and review results.
Select Deploy.
Navigate to Actions > Triggers and select Post-Login.
Locate your Action and drag it into the Login flow. Select Apply.

Configuring the Action via the Management API requires three steps: create the Action, deploy it, then bind it to the Login trigger. You need a Management API access token with create:actions, read:actions, and update:actions scopes.

Create the Action

Make a POST request to the Create an action endpoint:

POST https://YOUR_DOMAIN/api/v2/actions/actions
Content-Type: application/json
Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN

{
  "name": "Set session_expiry claim",
  "supported_triggers": [
    { "id": "post-login" }
  ],
  "code": "exports.onExecutePostLogin = async (event, api) => {\n  if (event.session?.expires_at) {\n    const exp_date = new Date(event.session.expires_at);\n    api.idToken.setCustomClaim('session_expiry', Math.floor((exp_date.getTime()) / 1000));\n  }\n};"
}

Note the id value in the response since you need it in the following steps.

Deploy the Action

Make a POST request to the Deploy an action endpoint:

POST https://YOUR_DOMAIN/api/v2/actions/actions/YOUR_ACTION_ID/deploy
Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN

Make a PATCH request to the Update trigger bindings endpoint:

PATCH https://YOUR_DOMAIN/api/v2/actions/triggers/post-login/bindings
Content-Type: application/json
Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN

{
  "bindings": [
    {
      "ref": {
        "type": "action_id",
        "value": "YOUR_ACTION_ID"
      },
      "display_name": "Set session_expiry claim"
    }
  ]
}

The PATCH /api/v2/actions/triggers/post-login/bindings request replaces all existing bindings. To preserve existing Actions in your Login flow, first retrieve your current bindings with GET /api/v2/actions/triggers/post-login/bindings, then include those bindings alongside the new one in your PATCH request.

Replace the placeholder values:

YOUR_DOMAIN: Your Auth0 tenant domain. Example: travel0.us.auth0.com.
YOUR_MANAGEMENT_API_TOKEN: A Management API token with create:actions, read:actions, and update:actions scopes.
YOUR_ACTION_ID: The id returned in the Create Action response.

Use session expiry with Auth0 SDKs

If you use Auth0 SDKs and have configured the Post-Login Action described above, session expiry is enforced automatically. The SDK reads session_expiry from the ID Token at login, persists it with the session, and treats the session as expired once the current time reaches or passes session_expiry:

SDK type	How expiry is enforced
Regular Web App (Next.js, Express, Python)	Middleware clears the session and redirects with `prompt=login`; `getAccessToken()` throws `SessionExpiredError`
Single-Page App (React, Angular, Vue)	`getTokenSilently()` / `getAccessTokenSilently()` rejects and triggers re-login with `prompt=login`
Mobile (iOS/Swift, Android/Kotlin)	`CredentialsManager.credentials()` returns `noCredentials` and the app’s existing login path handles re-authentication

The Post-Login Action is required to inject the session_expiry claim into the ID Token. Once set, when a session expires, the SDK behaves the same as any other session expiry: the user is redirected to log in. No additional error handling is required.

Add session expiry values to your application

An optional step is to add session expiration values to your application. For example, your application can read session_expiry to show users a session-expiring warning or you can bind your application’s own session lifetime to the upstream IdP’s value.

Single-Page App
Regular Web App
Mobile (Swift)

const claims = await auth0.getIdTokenClaims();
const sessionExpiresAt = claims?.session_expiry;   // Unix seconds
const remainingSeconds = sessionExpiresAt - Math.floor(Date.now() / 1000);

const session = await auth0.getSession();
const sessionExpiresAt = session?.sessionExpiresAt;   // top-level field, Unix seconds
const remainingSeconds = (sessionExpiresAt ?? Infinity) - Math.floor(Date.now() / 1000);

credentialsManager.credentials { result in
    switch result {
    case .success(let credentials):
        let sessionExpiresAt = credentials.idToken?.session_expiry   // Unix seconds
    case .failure:
        startLogin()
    }
}

Do not persist the session_expiry value in a long-lived store, such as a cookie or localStorage, without re-validating it on each read. The value is only meaningful relative to the current wall-clock time.

Verify in tenant logs

After enabling session expiry enforcement, verify session expiry is working by checking tenant logs. Navigate to Auth0 Dashboard > Monitoring > Logs and look for a successful login (s) event for a user authenticating through the configured Enterprise connection. When the upstream IdP’s session_expiry is less than or equal to your tenant’s configured absolute session lifetime, the log entry includes the idp_session_expiry field (a Unix timestamp in seconds):

{
  "type": "s",
  "description": "Success Login",
  "details": {
    "idp_session_expiry": 1782472241
  }
}

If the IdP did not send a session_expiry claim and you enable the feature, login fails with an error message: The upstream Identity Provider did not return a session_expiry claim.

Disable session expiry enforcement

Auth0 Dashboard
Management API

Navigate to Authentication > Enterprise in the Auth0 Dashboard.
Select the connection you want to configure.
Select the Settings tab.
Disable Use ID Token for Session Expiry.
Select Save.

Set id_token_session_expiry_supported to false in your connection options:

PATCH https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID
Content-Type: application/json
Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN

{
  "options": {
    "id_token_session_expiry_supported": false
  }
}

Before you start

​How it works

​Enable session expiry enforcement

​Send session expiration to your application

​Create the Action

​Deploy the Action

​Bind the Action to the Login trigger

​Use session expiry with Auth0 SDKs

​Add session expiry values to your application

​Verify in tenant logs

​Disable session expiry enforcement

​Learn more

How it works

Enable session expiry enforcement

Send session expiration to your application

Create the Action

Deploy the Action

Bind the Action to the Login trigger

Use session expiry with Auth0 SDKs

Add session expiry values to your application

Verify in tenant logs

Disable session expiry enforcement

Learn more