Tokens expire too fast or sessions too long: token lifetime vs session layers

Diagnose: token/session lifetime confusion

Symptom

Users complain about frequent logouts, or security review flags tokens living too long.

The four lifetimes

1. Access token lifetime: API settings (default 24h for custom APIs, shorter for Management API). exp in the token.
2. ID token lifetime: application settings.
3. Refresh token - absolute lifetime (hard cap from first issuance) and inactivity lifetime (idle expiry). Application > Refresh Token settings.
4. SSO session: tenant session layers (idle timeout, absolute timeout) under Dashboard > Settings > Advanced or Session Management.

Confirm

Decode the access token - exp - iat = the access token lifetime in force. Compare with the API setting. For sessions, check the tenant session settings and the application's refresh token settings side by side; the SHORTEST applicable lifetime wins the user's experience.

Tenant logs show token issuance; the absence of refresh events after the inactivity window confirms idle expiry is the limiter.

Fix

• Frequent logouts with a good refresh setup: the inactivity lifetime is too short, or the app is not using the refresh token (relying on the access token alone).
• Too-long sessions: tighten absolute lifetime first (the backstop), then inactivity.
• Never "fix" short sessions by minting 30-day access tokens. Use refresh rotation; access tokens stay short.

Verify

Set a test user, wait out (or simulate) each boundary, and confirm the behavior matches the intended layer. Document the four numbers in the runbook.

Auth0's token lifetime settings are documented in API settings (access token), application settings (ID token, refresh token rotation with absolute/inactivity lifetimes), and tenant session management docs. Verified against live docs 2026-09-26.