Sessions & logout
After a user authenticates, SemAuth keeps a server-side session so they don't have to re-authenticate on every visit. This page explains the realm session, how users review and revoke their own sessions, and how logout works.
The realm session
On successful sign-in (by any method) SemAuth sets a session cookie sa_session — an opaque random
token, HttpOnly, SameSite=Lax, and Secure over HTTPS. The server stores only
a hash of the token. A session lasts 12 hours.
The session records which method was used (and therefore its assurance level), the
user agent, and the IP address. When your app sends the user back to /authorize within the session's
lifetime — and the session meets the realm's assurance floor — SemAuth issues a code without showing the login page
again (this is silent SSO across all apps in the realm).
Self-service session management
A signed-in user can visit /sessions on the realm to see their active sessions and the application
grants they've approved:
- Active sessions — method, user agent, and IP, with the current session badged.
- Revoke a session — ends another session and revokes the refresh-token families tied to it. (You can't revoke your current session from the table — use logout.)
- Application grants — the apps the user has signed into, by client and scope, each revocable. Revoking a grant also revokes its refresh tokens.
Logout
There are two logout paths:
App-initiated (RP-initiated logout)
Your app sends the user to the realm's end_session_endpoint — GET /logout — with
id_token_hint set to the ID token it received at login, and optionally
post_logout_redirect_uri and state. SemAuth revokes the session, clears the cookie, and
sends the user back to your app when the redirect URI is registered for the app the hint names; otherwise it shows
a "logged out" page.
An expired ID token still works as a hint — that is usually exactly when an app wants to log someone out. If you
no longer hold one, send client_id instead.
First-party logout
The Log out button on the /sessions page revokes the current session and clears the
cookie.
Registering a post-logout URL. Add it under Post-logout redirect URIs
on the client, in the admin console (or send post_logout_redirect_uris when you create the client
through the API or dynamic registration). For post_logout_redirect_uri to be honored it must be
registered for the app the request identifies — one app's landing page is never reachable through
another's logout — and it is matched exactly. A URI that doesn't match simply lands the user on the SemAuth
logged-out page (this prevents open-redirect abuse).
A logout request that names no app at all gets neither: SemAuth shows a confirmation page rather than ending a session, because it has no way to tell your logout link from one a user was tricked into following.
Tokens vs. sessions
The realm session (browser cookie) is separate from the OAuth tokens your app holds. Revoking a session ends SSO and kills associated refresh tokens, but already-issued access tokens follow their own lifecycle:
- Opaque access tokens (
sa_at_…, the default for user flows) can be revoked server-side and stop working immediately. - JWT access tokens (issued when an
audienceis requested) are stateless and valid until they expire (1 hour) — they cannot be revoked individually.
See the OIDC reference for token formats, lifetimes, and the revocation endpoint.
Administrator-driven revocation
Deactivating a user in the admin console immediately revokes all of that user's sessions and tokens. See Managing users & activity.