Sessions & SSO

When a user signs in, the issuer sets a session cookie on its own host. That session is what makes single sign-on work: a second application under the same issuer finds an existing session and logs the user in without another password prompt. The session lives at the issuer, not in your app — which is why signing out of your app is not enough to sign out of auth.is (see logout, below).

The issuer session

The session cookie is signed, httpOnly, and sameSite=lax, and its name is scoped per issuer (authis.{slug}.session). Host isolation is the tenancy boundary: a session at acme.auth.is is invisible to other.auth.is, so SSO never crosses issuers — only clients of the same issuer share a session.

A session's default lifetime is 14 days. The issuer carries a sessionTtlSeconds setting (bounds 300–2,592,000, i.e. 5 minutes to 30 days) for tuning how long a login session stays valid; set it with update_issuer_settings. See Issuers for the settings bag.

SSO across clients of one issuer

Because the session lives on the issuer host, the second client's authorization request arrives with the session cookie already present. First-party clients skip the consent screen (their grant is loaded automatically); a third-party client hits consent the first time. Either way the user does not re-enter a password.

Steering the prompt

Two standard OIDC prompt values let your client override the default SSO behaviour on a given authorization request:

• prompt=login forces a fresh authentication even if a session exists — use it for a step-up or a "confirm it's you" moment. Because it re-authenticates, it also re-arms the passkey second factor.
• prompt=consent forces the consent screen to run again. This is also the required companion to offline_access when you want a refresh token — offline_access is only honored when the request carries prompt=consent. See Scopes & claims and Token lifetimes & refresh.

Signing out (RP-initiated logout)

Clearing your app's local session leaves the issuer session intact — so your next "Sign in" logs the user straight back in with no visible interaction, which looks like sign-out is broken. To actually end the session, redirect the browser to the issuer's end-session endpoint so it clears its own cookie:

https://{slug}.auth.is/oidc/session/end?client_id=…&id_token_hint=…&post_logout_redirect_uri=…

The post_logout_redirect_uri must be on the client's post-logout redirect URI list (set it with update_client). Register a path distinct from your sign-in callback so your app can tell a completed sign-out from a sign-in. The curl guide, §9 walks the full logout redirect.

Grants get swept on password reset

A session cookie is not the only thing that keeps a user signed in — a first-party grant and any offline_access refresh token do too. So a password reset revokes the account's sessions and grants (and their tokens) inside the issuer, in the same action that replaces the credential. A pre-reset session cookie stops auto-authorizing and any refresh token stops working immediately — not at expiry. The same server-side sweep backs token revocation.

Next steps