Sessions and Single Sign-On
A session records that a user authenticated, so ThunderID can trust that authentication again later without prompting the user to repeat it. Single Sign-On (SSO) builds on sessions: when a user has a valid session, ThunderID reuses it and skips the steps the session already covers.
This page explains the session model and how SSO applies to authentication flows. To add SSO to a flow, see Single Sign-On for Flows.
Flow-Centric Sessions
ThunderID ties each SSO session to a single flow. The flow is the grouping key: every application that authenticates through the same flow shares that flow's session, and two different flows never share a session.
Because the flow is the grouping key, you can group sessions by the security category of the applications. Assign applications that share a security category to the same flow so they reuse one authentication. Put applications in a more sensitive category on a separate flow, so a session established for a lower-category application never signs the user in to a higher-category one.
Checkpoints
A checkpoint is the authentication that SSO can skip and reuse. You define it with a pair of nodes: a Check SSO Session node marks where the reusable authentication begins, and a Save / Load Session node marks where it ends. The checkpoint covers the authentication steps between them.
On a fresh sign-in, the flow runs those steps and saves the checkpoint under the session. On a later sign-in, the flow reuses the checkpoint and skips the steps it covers. If the checkpoint has expired, the user completes the steps again.
Session Lifetime
Two independent timeouts bound every session:
| Timeout | Behavior | Default |
|---|---|---|
| Idle | Moves forward on each use of the session, so an active session stays alive. The session expires after this much inactivity. | 30 minutes |
| Absolute | Fixed when the session is created and never extended. The session expires this long after creation regardless of activity. | 8 hours |
A session expires when it passes either deadline. After expiry, the next sign-in through the flow authenticates the user again. An administrator configures both timeouts in the server configuration. See Configure Session Lifetime.
Browser Scope
Flow SSO applies to browser-based authentication. ThunderID references each session with a per-flow cookie that carries only an opaque handle, never user data. Because the cookie is the reference, SSO reuse happens within a browser: a user who authenticates in one browser does not gain a session in another.
Ending a Session
Signing a user out of an application does not, on its own, end their ThunderID session. Because SSO reuses the session, the next sign-in would find it still valid and skip authentication. To sign the user out fully, terminate the session at ThunderID as well.
A session is terminated by running the application's sign-out flow, which ends the session and clears its per-flow cookie. Terminating a session is idempotent: ending an already-ended or expired session is not an error.
Every application resolves a sign-out flow from the first of three sources that is set: the flow pinned on the application, the default on its organization unit, or the server-level default. ThunderID ships a server-level default, so an application that pins nothing still signs users out. See Build a Sign-Out Flow.
There are two ways to run the sign-out flow, matching the two integration models:
- Redirect-based (OIDC). A browser-based application redirects the user to the
end_session_endpoint, which runs the sign-out flow and returns the browser to the application. See RP-Initiated Logout. - App-native. An application that drives flows directly runs the sign-out flow through the Flow Execution API. See Build a Sign-Out Flow.
A session also ends on its own when it passes the idle or absolute timeout, as described above.
Related
- Single Sign-On for Flows shows how to add the SSO nodes to a flow in the Console Flow Builder.
- RP-Initiated Logout shows how a browser-based application ends the session over OIDC.
