Logout and Session Management

Calling POST /logout on a client application typically does exactly one thing: it destroys that application’s own session (clears its cookie, invalidates its server-side session record). The authorization server’s session is untouched. The practical consequence:

None of this is a bug in Client A or Client B individually — both behaved correctly for a pure OAuth/OIDC login. It is a gap that only single logout, described below, closes.

OpenID Connect RP-Initiated Logout 1.0 gives the client (the "Relying Party", RP) a way to ask the authorization server to end its own session too, and to send the browser back somewhere sensible afterwards:

The AS clears its own SSO session cookie and redirects:

This closes the gap above for a single client-initiated logout — but it only ends the AS’s session and redirects one browser. It does nothing, by itself, for the other clients that browser is still logged into elsewhere; that is what front-channel and back-channel logout add.

Front-Channel Logout 1.0 lets the authorization server notify every other client with an active session at the moment it processes a logout (RP-initiated or otherwise): it renders a hidden <iframe> per registered client, pointed at that client’s frontchannel_logout_uri, so each client’s own logout endpoint runs inside the user’s browser and can clear its own cookie:

This depends on the browser actually loading and executing each client’s page inside a third-party iframe context — exactly the context modern browsers increasingly restrict or partition (Safari’s Intelligent Tracking Prevention, Chrome’s phase-out of unpartitioned third-party cookies, Firefox’s Total Cookie Protection). A client whose own session cookie is SameSite=Lax or Strict, or whose storage is partitioned per top-level site, may simply fail to see or clear its session when its logout endpoint runs inside someone else’s page. Front-channel logout therefore now fails silently, unpredictably, and in a browser-dependent way — it cannot be relied on as the only single-logout mechanism.

Back-Channel Logout 1.0 avoids the browser and third-party-cookie problem entirely by having the authorization server call each client’s logout endpoint directly, server to server, with a signed logout token:

Decoded, the logout token is a purpose-built JWT, not a reused ID token:

The client verifies the signature, iss, aud, exp and jti (replay protection) exactly as it would an ID token, confirms events contains the back-channel-logout member, then ends the local session identified by sid (or by sub, if it does not track individual sid values) — entirely server-side, with no browser, no third-party cookie, and no dependency on the user’s current tab even being open. Because it runs out of band, it is the mechanism that actually works under current browser third-party-cookie policy, and it is the one to build single logout on for any new integration; front-channel logout should be treated as a legacy fallback for clients that cannot expose a server-to-server endpoint, not the primary mechanism.

OpenID Connect Session Management 1.0 predates both logout specifications above and takes a different, poll-based approach: the client embeds a hidden <iframe> pointed at the AS’s check_session_iframe, and periodically posts a message into it (via postMessage) asking "has this session changed?". The AS’s iframe script reads its own first-party session cookie (first-party from the AS’s point of view, third-party from the client page embedding the iframe) and posts back "changed", "unchanged" or "error".

This mechanism is built entirely on the AS’s session cookie being readable inside a third-party iframe context on the client’s page — precisely the access browsers now restrict by default. Where third-party cookies are blocked or partitioned, the check-session iframe cannot see the AS’s real session state, so it reports stale or incorrect results (typically "changed" on every poll, since the AS can no longer tell the browser apart from a fresh, cookie-less visitor). Session Management 1.0 should therefore be treated as effectively obsolete in any browser environment; Back-Channel Logout is the reliable current answer to the same underlying problem (learning that a session ended elsewhere), because it does not route through the browser’s cookie jar at all.

A user is frequently logged into the same client from several browsers or devices at once, and a single logout action — "log out of this browser" — should not necessarily end every one of them. The sid (session ID) claim, present in both the ID token and the logout token, scopes a logout to one authorization-server session rather than to the user account as a whole:

Getting this distinction wrong in either direction is user-visible: treating every sid-scoped logout as account-wide logs a user out of devices they never asked to end; treating every sub-scoped forced logout as sid-scoped leaves compromised sessions alive on other devices exactly when an administrator most needed them gone.

Ending a session and revoking a token are related but distinct: a session end should trigger token revocation, but a still-valid, unexpired access or refresh token is a separate live credential that keeps working against a resource server until either it expires or is explicitly revoked. POST /oauth2/revoke (RFC 7009) is how a client or authorization server invalidates a specific token immediately; the full mechanics, including why a locally validated JWT access token cannot be revoked before its own exp, are covered in Opaque Tokens, Introspection and Revocation. A thorough single-logout implementation calls revocation for every token issued in the ending session, in addition to clearing cookies and acting on any back-channel logout token received.

In a backend-for-frontend deployment (see Browser-Based Apps), the browser only ever holds a session cookie to the BFF; the BFF alone holds the OAuth tokens. This concentrates single logout into one place instead of spreading it across every downstream microservice:

A topology without a BFF — several independently-cookied client applications, each with its own session — has to implement front-channel and/or back-channel logout on every single one of them, which is exactly the fan-out the diagram below shows.