A session is the server-side record that keeps a user signed in after a successful login. This page covers how long a session lasts, what renews it, how concurrent logins are handled, and everything that can end one.

Overview

A session is created only after every login check — including MFA — passes, whether the login used a password, SSO, or OTP. It stores who the user is, their tenant and app, their language and time zone, and its own expiry time. The browser holds only an opaque session ID in a secure, HttpOnly cookie: no credentials or personal data live in the cookie, it isn't readable by page scripts, and it's sent over HTTPS only. Every request is validated against the server-side record, so ending a session on the server signs the browser out instantly regardless of the cookie.

Use Cases

• Set a shorter Session Expiry Time for a sensitive sign-in method, and a longer one for low-risk internal tools.

• Enable Perpetual Login so returning users aren't prompted to sign in every day.

• Restrict a method to one active session per user so a shared password can't be used from two places at once.

• Diagnose an unexpected logout by checking what ended the session.

• Distinguish a genuine logout from a session timeout when reviewing activity.

Session Lifetime and Renewal

Each sign-in method sets its own Session Expiry Time, in minutes, in Settings › Security; when unset, the platform default is 24 hours. The clock isn't a hard cutoff for active users: whenever a request lands within the last 5 minutes of a session's life, the platform quietly extends the session by a full duration and refreshes the cookie to match. In practice, the Session Expiry Time behaves as an inactivity timeout — while you keep working you stay signed in indefinitely, and you're logged out only after being away long enough for the window to run out.

Perpetual Login (Refresh Tokens)

If Perpetual Login is enabled on the sign-in method, login also issues a separate refresh token in its own secure cookie. When the session itself has expired, the platform silently exchanges the refresh token for a brand-new session instead of bouncing the user to the login page. The refresh token lives for the method's Refresh Token Expiry Time, in days (default 30 days), and is re-armed on each use — so a user stays signed in as long as they return at least once within that window.

Note: anything that deletes a user's sessions — an admin reset, a Restrict Multiple Sessions eviction, logout, or account deletion — deletes the paired refresh token too, so Perpetual Login can't resurrect a revoked session.

Concurrent Logins

By default, concurrent sessions are unlimited — a user can be signed in on several devices or tabs at once, and each login gets an independent session. Two per-method switches change that:

• Restrict Multiple Sessions: every new login first deletes all of the user's existing sessions and refresh tokens and pushes a real-time sign-out to the other devices. One active session, ever — the newest login wins.

• Single Tab Session: the platform tracks that one browser tab has claimed the session; opening it in a second tab triggers a full sign-out of the session everywhere.

What Ends a Session

Termination is immediate: the very next request with a dead session gets a 401 and the browser returns to the login page. Changing a user's State to Disabled or Locked blocks new logins but doesn't by itself end sessions already open, and a user changing their own password via Change Password keeps all their sessions.

What Happens the Moment a Session Expires

Expiry is handled server-side: the session record is removed, a "session expired" entry is written to the user activity report, and a user-logout event fires for any tenant webhooks listening — the same reporting as an explicit logout, so admins can distinguish "logged out" from "timed out" in activity views. The browser finds out on its next request (a 401 redirects to the login page), and the user returns to what they were doing after signing back in.

Auditing Sessions

Every login (with session ID and source IP), logout, session expiry, failed login, and account lock is captured in the user activity report, and login/logout/login-failed events are published to tenant webhooks — so security teams can feed them into a SIEM. Sign-in method, tenant, and app are recorded on the session itself.

If you're building automations on the login/logout webhooks: the identity-provider reference field is identityProviderId on the failed-login payload, alongside the failure reason, username, IP address, and timestamp; a successful login's payload is the full user record, whose identity-provider field is idp. The Activity report itself (behind Settings › Users › Activity, including its export) does not have an identity-provider column — its fields are session ID, activity type, user, login time, logout time, application, and IP address, plus a failure reason on failed attempts. To break logins down by identity provider, pull that reference from the webhook payload or the user record instead.

Notes

A few habits keep session behavior predictable for your users:

• Set Session Expiry Time deliberately per method rather than relying on the 24-hour default everywhere.

• Enable Perpetual Login for low-risk methods where you want to minimize repeat sign-ins.

• Turn on Restrict Multiple Sessions for methods where one active session per user genuinely matters.

• Remember that disabling a sign-in method doesn't end sessions already created through it.

• Use the login/logout webhooks, not the Activity report export, if you need to break sign-ins down by identity provider.

Understood this way, session behavior is a small set of levers — expiry, renewal, and concurrency — that together decide how often your users have to sign back in.