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 — optionally
with post_logout_redirect_uri and state. SemAuth revokes the session, clears the cookie,
and (if the redirect URI is registered for a client in the realm) sends the user back to your app; otherwise it shows
a "logged out" page.
First-party logout
The Log out button on the /sessions page revokes the current session and clears the
cookie.
Registering a post-logout URL. For post_logout_redirect_uri to be
honored, it must be a registered post-logout redirect URI for a client in that realm — otherwise the user simply
lands on the SemAuth logged-out page (this prevents open-redirect abuse).
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.