skip to content

When an OpenID Provider notifies relying parties through `frontchannel_logout_uri`, why does the chain clear only some sessions?

level: seniorimportance: must knowfreq 52%

answer

  1. everything happens inside one page
  2. one hidden frame per relying party
  3. the browser's own cookie rides along
  4. nobody signs for a delivery
  5. close the tab, the chain stops

basics

~20 s

Front-channel logout renders one hidden frame per relying party on the provider's logout page. Every frame must load and finish in that browser before the user leaves, nothing is acknowledged, and nothing retries, so any frame that fails is a session left open.

solid answer

~50 s

The provider builds its logout page with one hidden frame per relying party that registered a `frontchannel_logout_uri`, and each frame is an ordinary request the **browser** makes — which is the point, because the relying party's own cookie rides along and it can act on its session. The chain is therefore only as good as that page's lifetime: a user who closes the tab, a frame the user agent will not load cross-site, a relying party that refuses to be framed, or one whose endpoint is slow or errors, all end the same way — that relying party is never told. Crucially **nothing is acknowledged**: the provider learns nothing about which frames succeeded, so it cannot retry and cannot report. `frontchannel_logout_session_required` decides whether `iss` and `sid` are appended, and the relying party MAY, not MUST, check them against an ID token it holds.

code

http · 6 lines
http
GET /oidc/frontchannel-logout?iss=https%3A%2F%2Fidp.example&sid=08a5019c-17e1-4977-8f42-65a12843ea02 HTTP/1.1
Host: roster.example
Cookie: roster_session=6fb2c1e0d4a9

HTTP/1.1 200 OK
Content-Length: 0

go deeper

for a junior

Recall that the provider signs other applications out by loading a hidden page for each of them in the same browser, and that anything which stops those pages loading stops the sign-out.

for a middle

Explain why the mechanism runs in the browser at all — the relying party's cookie rides along — and what the iss and sid parameters add when they are present.

for a senior

Show the diagnosis: a logout that completes on three relying parties out of five, with no error anywhere, because frames are unacknowledged and the provider retries nothing.

for a principal

The judgment is what to promise. Front-channel coverage cannot be measured from the provider, so an estate depending on it alone has a guarantee nobody can audit.

## How the chain is built When a provider ends a session — because a relying party sent it to the `end_session_endpoint`, or because the user signed out on the provider's own page — it needs to tell the other relying parties. Front-channel logout does that by rendering, on the logout page it is already showing, one hidden frame per relying party that registered a `frontchannel_logout_uri`. Each frame causes the browser to make a plain request to that relying party's URI. The reason to do it this way, rather than from the provider's servers, is exactly the reason RP-initiated logout is a redirect: **a request made by the browser carries that browser's cookies.** The relying party receiving the framed request sees its own session cookie and can therefore act on the very session the user is looking at. ## What the request carries | Metadata member | Registered by | What it controls | |---|---|---| | `frontchannel_logout_supported` | the provider | Whether the provider offers the mechanism at all | | `frontchannel_logout_uri` | the relying party | The address the provider frames on its logout page | | `frontchannel_logout_session_required` | the relying party | Whether `iss` and `sid` are appended to that address | When `frontchannel_logout_session_required` is registered true, the provider appends `iss`, naming the issuer, and `sid`, naming **one provider session** — not the user. The relying party MAY verify those against the claims of an ID token it holds before acting. That is a MAY: the specification does not oblige it, and an answer that upgrades it to a MUST is teaching a false certainty. Where the parameters are absent, the relying party can only act on whatever session its own cookie identifies, which is ambiguous the moment a browser holds more than one session with that provider. ## Where the chain breaks Every one of these leaves a session open, and none of them produces an error anybody sees: - The user closes the tab, or navigates away, before the last frames have loaded. The chain simply stops where it is. - The user agent declines to load a cross-site frame, or declines to send the relying party's cookie inside one. The request may not happen, or may happen without the cookie that makes it meaningful. - The relying party refuses to be rendered inside another site's frame — a reasonable hardening choice that silently disables its own logout notification. - The relying party's endpoint is slow, is down, or returns an error. Nothing about the page notices. - The relying party never registered a `frontchannel_logout_uri` at all, so no frame exists for it. - The relying party's session lives in a different browser entirely — the vehicle tablet while the logout ran on the phone. There is no frame that can reach it, by construction. ## The part candidates miss: there is no acknowledgement A framed request produces a response the browser consumes; the provider gets nothing back. It cannot tell a completed logout from a frame that never loaded, so it **cannot retry and cannot report**. This is the structural difference from back-channel notification, where the provider makes the request itself and sees the outcome. Anyone designing sign-out for an estate should understand that front-channel coverage is not measurable from the provider's side — which means an estate relying on it alone has no way of knowing how well it works. ## Front-channel is not a synonym for insecure A common reflex is to grade the two mechanisms as 'insecure' and 'secure'. That is the wrong axis. The framed request is made by the user's own browser to the relying party's own endpoint over the same transport as everything else; it is not intercepted or forged by being in the front channel. What distinguishes the two is **reach and reliability**: the front channel can act on browser state and cannot be confirmed; the back channel can be confirmed and cannot touch browser state. The failure to fix is the one where an estate treats them as substitutes. ## What a relying party should do with the request Given `iss` and `sid`, it can end precisely the session those name. Given neither, its only handle is its own cookie — which is correct when a browser holds one session and wrong when it holds two. Either way the relying party responds to the framed request and the user sees nothing; the logout page the user is looking at belongs to the provider, and the frames are invisible by design.

  • What does `frontchannel_logout_session_required` change about the request the provider sends?
    Registered true, it makes the provider append `iss` and `sid`, so the relying party knows which issuer sent the notice and which provider session it names. Registered false, a bare request arrives and the relying party can only act on whatever session its own cookie identifies — ambiguous if that browser holds more than one.
  • Why can back-channel logout not simply replace the front-channel chain?
    A back-channel notification reaches the relying party's server out of band and never touches the user agent, so nothing the browser holds is affected by it. The framed request runs inside the browser where the relying party's cookie lives. They fail in different places, which is why estates that care run both.
  • The provider's logout page renders and the user is returned to the relying party. What has that proved about the other relying parties?
    Nothing. The frames are invisible and unacknowledged, so a completed logout page is consistent with every other relying party having been notified and with none of them having been. Front-channel coverage is not observable from the provider's side.

Front-channel logout is a stack of notes handed to a courier who is already on his way out of the building: every delivery has to happen before he reaches the door, and nobody signs for any of them.

saying these in an interview costs you the question

  • Believes the provider retries a front-channel frame that failed to load
  • Thinks a relying party MUST validate the iss and sid parameters
  • Assumes the chain reaches sessions in a different browser
  • Reads front-channel as insecure and back-channel as secure
  • Expects the provider to know which relying parties actually signed out
  • Treats sid as naming the user rather than one provider session