Session State and Logout

## The endpoint and what it is for An OpenID Provider that supports relying-party-initiated logout advertises an `end_session_endpoint` member in its configuration document. A relying party that wants to end the user's session **at the provider** — not merely its own — sends the user agent there. The whole point of making it a redirect rather than a server-to-server call is that the provider's session lives in a cookie held by that browser: only a request the browser makes carries it, so only a request the browser makes lets the provider recognise the session and drop it. This is one of four separate session-related documents in the OpenID Connect family, and it is the one with the clearest contract: a single request, one visible effect at the provider, and an optional return trip. ## The parameters | Parameter | Strength | What it does | |---|---|---| | `id_token_hint` | RECOMMENDED | A previously issued ID token, replayed as a request parameter, telling the provider which end-user session and which client this logout is about | | `logout_hint` | OPTIONAL | A provider-specific hint about which end user is meant, for cases where no ID token is available | | `client_id` | OPTIONAL | Identifies the requesting client; when both it and `id_token_hint` appear they must name the same client | | `post_logout_redirect_uri` | OPTIONAL | Where to send the browser afterwards; must have been registered for that client in `post_logout_redirect_uris` | | `state` | OPTIONAL | Opaque value echoed back unchanged on the return redirect | | `ui_locales` | OPTIONAL | Preferred languages for any page the provider renders during logout | The strengths matter. A candidate who says `id_token_hint` is required has learned one provider's behaviour rather than the specification: it is RECOMMENDED, and a request without it is still a valid logout request. What it buys is precision — with it the provider knows exactly which session and which client are involved, and can verify a `post_logout_redirect_uri` against that client's registration without asking anyone anything. ## Why registration of the return URI is not optional in practice The provider must not redirect the browser to a `post_logout_redirect_uri` whose validity it has not established. Without that rule the logout endpoint becomes an open redirector wearing a trusted hostname: anyone could hand a user a link to the provider that bounces them onward to a page of the attacker's choosing, with the provider's domain in the address bar for the first hop. So the provider needs either an `id_token_hint` or a `client_id` to know whose registered list to check against; given neither, it should end the session and render its own page instead of redirecting. ## What happens, in order 1. The relying party builds the logout URI and redirects the browser to it. 2. The provider receives the request with its own session cookie attached, and identifies the session — from the cookie, refined by `id_token_hint` or `logout_hint` if present. 3. The specification permits the provider to ask the end user to confirm, and providers commonly do so when the request carries no `id_token_hint`, because a bare request is an unauthenticated instruction to end somebody's session. 4. The provider ends its own session for that user agent. 5. The provider notifies other relying parties, by whichever of the front-channel and back-channel mechanisms each of them registered. That notification is a separate mechanism with its own failure modes. 6. If a `post_logout_redirect_uri` was supplied and verified, the provider redirects there, appending `state` unchanged if one was sent. ## What this request does not do - It does not, by itself, end any relying party's own application session. That is the relying party's job, triggered either by its own handling of the redirect or by a notification from the provider. - It does not invalidate credentials the provider has already issued. Token lifetime and revocation are a different subject with a different endpoint entirely. - It does not reach other browsers. The vehicle tablet, the phone and the desktop each hold their own provider session cookie; a logout in one of them is a logout of that one, plus whatever notification the provider manages to deliver to relying parties in that same browser or to their servers. ## The word 'state' is overloaded here Three different values share that word on this material: the `state` parameter on an authorization request, which binds a login response to the request that started it; the `state` parameter on this logout request, which is just a round-tripped bookmark; and `session_state`, which is a provider-computed digest and not a client-chosen value at all. In an interview, say which one you mean before you say what it does.