In an OpenID Connect estate whose relying parties do not all support back-channel logout notification, how would you define and deliver 'signed out everywhere'?

## First, decide what the promise is The failure in most estates is not technical; it is that somebody wrote 'signing out signs you out everywhere' into a policy document that the protocol cannot honour. Three mechanisms exist, each fails somewhere different, and none of them is transactional. A lead's first job is to replace one unprovable sentence with three provable ones. ## The three tiers | Tier | What it covers | Confidence | |---|---|---| | The provider session ends | The user agent that made the logout request no longer has a session at the provider | Guaranteed, synchronous | | Relying parties are notified | Back-channel POSTs to registered servers; framed requests in that one browser | Best effort; only the back-channel half is observable | | Relying-party sessions expire | Everything the notification missed | Time only | The first tier is more valuable than it looks. Once the provider session is gone, no relying party in that browser can be silently signed in again without a real authentication; the estate stops leaking new sessions the moment the request is handled. That is the part worth promising in writing. ## What to require at onboarding The estate's weakest relying party sets its real guarantee, so the lever that actually moves the number is admission, not engineering: 1. **A registered `backchannel_logout_uri`** from any relying party holding server-side state. It is the only channel whose outcome the provider can see, and therefore the only one you can report on. 2. **A registered `frontchannel_logout_uri`** from any relying party holding browser state, because a back-channel POST cannot reach it. 3. **`backchannel_logout_session_required`** wherever one person may hold several sessions at the provider, so the token carries a `sid` and the relying party ends the right one rather than all of them. 4. **A stated maximum session lifetime** from any relying party that will register neither. That number, not the logout mechanism, is that application's real exposure after a sign-out. ## What you can measure The provider observes the result of every back-channel POST it makes and observes **nothing at all** about a framed request. So the only honest dashboard is built from back-channel outcomes: which relying parties were notified, which returned errors, which timed out. A relying party whose logout endpoint has been failing for a month is an outage you can see; the same failure in the front channel is invisible to everyone. This asymmetry is a strong reason to make the back channel the baseline requirement and the front channel the supplement, rather than the other way round. ## The costs you are trading - **Requiring back-channel support narrows who can integrate.** Some relying parties genuinely cannot expose a callable endpoint, and the answer for them is short sessions, not an exception to the policy. - **Short session lifetimes cost re-authentication friction**, and on a device being used with cold hands at night that friction is not theoretical. - **Polling session state costs battery and provider capacity** on every open tab, and rests on cross-site cookie behaviour you do not control, so it is a poor foundation for a guarantee even though it is useful as a hint. - **Running both notification channels costs every relying party two endpoints** to build and keep working. ## The incident case, which is the one people actually mean When the requirement is 'end this person's access now' — a device lost during a callout, an account believed compromised — reason about it in the same tiers rather than reaching for the logout button and assuming. Ending the provider session is immediate and stops further sign-in. Notification is best effort and may never arrive at some relying party. What a device can still do with credentials already issued to it is a **token lifetime** question, with its own mechanisms and its own owner, and treating logout as though it answered that question is the single most expensive misunderstanding in this area. ## What is out of scope of this decision How each relying party records that a session is dead, and what its own store looks like, is that team's design problem. The estate-level decision is narrower and sharper: which metadata members every integrating party must publish, what maximum session lifetime the exceptions accept, and which of the three tiers the policy document is allowed to promise.