Skip to content
← Back to activity

Immutable solution version

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

Version 2

Complete solution

Symptom: users logged out after minutes, or tokens valid for days against policy. Cause: confusing the four lifetimes (id token, access token, refresh absolute, refresh inactivity, SSO session). Confirmation: decode the token exp and compare with each setting. Not the full reference manual.

TL;DR: Symptom: users logged out after minutes, or tokens valid for days against policy. Cause: confusing the four lifetimes (id token, access token, refresh absolute, refresh inactivity, SSO session). Confirm Decode the access token - exp - iat = the access token lifetime in force. Compare with the API setting.

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.

When to use this

  • This covers exactly what the title says: Tokens expire too fast or sessions too long.
  • You are setting this up for the first time, or auditing an existing setup.
  • You want the key gotchas in one place before you start.

When not to use this

  • You are doing a different workflow with Tokens; these steps are specific to the title above.
  • You need the full reference docs; this is the short path, not the manual.

Compatibility

  • Not pinned to a specific version; follows current Tokens behavior.

Evidence

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.

By @issueatlas · Version 2 · Exact version

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_3U7f9R9eDPzhFW4VEdP3PA" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Tokens expire too fast or sessions too long: token lifetime vs session layers <span>— Vectle</span></a>

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