Sessions and logout

Three sessions are involved when someone uses your app: their SSO session at sso.aldelo.com, their app session with your app, and your app's own session. This page explains how they relate and how to end them together.

App sessions and sid

Each time a person signs in to your app, SSO creates or reuses an app session: one per SSO session, per app, per organization. Its ID is the sid claim in the ID token and the access token.

• A later sign-in in the same browser, to the same app and organization, reuses the app session and its sid.
• Switching organization, or any fresh authentication (for example one forced by prompt=login or max_age), starts a new app session with a new sid.

When app sessions end

An app session ends when:

• its SSO session ends: the person signs out through any app, SSO detects a stolen refresh token and contains the theft, or a fresh authentication supersedes it. Every app session under that SSO session ends at once;
• its organization is deleted. The person's SSO session stays; only that organization's app sessions end;
• the person's account is erased;
• it, or its parent SSO session, simply runs out — reaches its own idle or absolute expiry. This one is different: see the warning below.

If your app registered a back-channel logout URI, SSO tells it about each of the events SSO can announce. See Back-channel logout.

Sign a person out

End your own session first, then send the browser to the end-session endpoint:

GET https://sso.aldelo.com/logout
  ?id_token_hint=eyJhbGciOiJSUzI1NiJ9.example.signature
  &post_logout_redirect_uri=https%3A%2F%2Fapp.example.com%2Fsigned-out
  &state=af0ifjsldkj-state

• id_token_hint (required): an ID token SSO issued to your app. It must not have expired.
• post_logout_redirect_uri (optional): where to send the browser afterwards. It must exactly match one of your registered redirect URIs. Without it, SSO shows a signed-out page.
• client_id (optional): your client ID. If you send it, it must match the hint's audience.
• state (optional): returned unchanged on the redirect.

SSO ends the browser's SSO session when the hint belongs to it, which also ends every app session under it. A hint from another session never ends the current one, but the redirect still happens. A request SSO can't validate shows an error page and never redirects.

Back-channel logout

If your registration has a back-channel logout URI, SSO posts a logout token to it, server to server, for each app session that ends:

POST /backchannel-logout HTTP/1.1
Host: app.example.com
Content-Type: application/x-www-form-urlencoded

logout_token=eyJhbGciOiJSUzI1NiJ9.example.signature

The logout token is a JWT signed like an ID token. A decoded payload looks like this:

{
  "aud": "example-app",
  "events": {
    "http://schemas.openid.net/event/backchannel-logout": {}
  },
  "exp": 1700000120,
  "iat": 1700000000,
  "iss": "https://sso.aldelo.com",
  "jti": "00000000-0000-0000-0000-000000000000",
  "organization_id": "00000000-0000-0000-0000-000000000000",
  "sid": "00000000-0000-0000-0000-000000000000",
  "sub": "00000000-0000-0000-0000-000000000000"
}

1. Validate the signature, iss and exp as you would for an ID token, and check that aud — a plain string here, unlike the access token's — is your client_id. Logout tokens are short-lived.
2. Check that events contains http://schemas.openid.net/event/backchannel-logout.
3. End your session whose sid matches. A logout token with no sid means end every session for that sub — sent on account erasure, and on organization deletion but only to that organization's own registered apps.
4. Answer with any 2xx status, quickly. SSO retries a failed delivery briefly and then gives up.

Organization deletion splits by whose app it is. Your app's own back-channel logout URI gets the sub-only token above only when your app is registered to the deleted organization. A multi-organization app that had a live app session for one of the deleted organization's members instead gets one sid-bearing token per ended app session, naming that organization_id — never the sub-only shape.

Check that a session is live

Back-channel delivery is best effort. Before an action that matters, confirm the session is live: call /userinfo with the access token, or introspect it. Both stop accepting the token once its app session has ended, even before exp.