Sessions

A session represents a user's authenticated browser session at the hosted login. It's separate from the tokens your app holds: the session is what lets a returning user skip re-authenticating, while your tokens are what authorize your app's own requests.

Where session state lives

NamoID is stateless at the app tier — any container can serve any request. Session records are persisted in the database and cached in Redis with a TTL. Lookups check the cache first and fall back to the database, so killing or scaling containers never drops a session. This is why there's no "warm cache" assumption and why the service scales horizontally without coordination.

Session lifecycle

• Established when a user completes a sign-in at the hosted login. The session is carried in an HttpOnly, SameSite=Lax signed cookie scoped to the hosted-login domain.
• Reused on the next visit — a returning user with a live session can be issued a fresh authorization code without re-entering credentials (subject to your prompt settings).
• Ended explicitly via logout, or implicitly when the session TTL elapses.

Logout

NamoID implements OIDC RP-Initiated Logout (the End Session endpoint). Your app redirects the user to the issuer's end_session_endpoint with an id_token_hint and an optional post_logout_redirect_uri. NamoID ends the hosted-login session and returns the user to your app. The endpoint is only advertised on hosted (per-environment) issuers, since only those have a browser session to end.

Logging out of NamoID ends the NamoID session; your application is responsible for clearing its own local session/cookies too. A typical logout flow clears the app session, then redirects to the End Session endpoint to clear NamoID's.

Revocation

• Token revocation — call the revocation endpoint to invalidate a refresh token.
• Refresh-chain revocation — replaying a rotated refresh token, or ending a session, revokes the associated refresh chain so stale tokens stop working.
• Account changes — password resets and account deletion revoke sessions and emit audit events.

App-side sessions

For server-rendered apps, keep your own session server-side and store NamoID tokens there, never in localStorage. Use HttpOnly, SameSite=Lax cookies. The quickstarts follow this pattern: tokens live in the server session (or a backend-for-frontend), and the browser only ever holds a signed session cookie.