How does the SAML Single Logout protocol work, and why is it fragile in practice?

When the user logs out at one party, the IdP (the session authority) sends a <LogoutRequest> naming the session to every SP that received an assertion in that session and collects the <LogoutResponse>s; it breaks easily because one unreachable or misbehaving SP leaves a session alive.

* SP-initiated Single Logout: the IdP knows every session participant and propagates the logout to each. *

1. The user clicks "log out" at SP A. SP A ends its local session and sends a <LogoutRequest> (with the NameID and SessionIndex) to the IdP.
2. The IdP looks up every other SP it issued assertions to in this session and sends each a <LogoutRequest>.
3. Each SP terminates its local session and answers with a <LogoutResponse>.
4. The IdP ends its own session and returns a final <LogoutResponse> to SP A, which reports whether logout was complete or partial.

The weak spots: with front-channel logout the browser must visit every SP in turn, so closing the tab, a slow SP or a blocked third-party cookie stops the chain; with back-channel (SOAP) logout the IdP needs direct network access to every SP. Many SPs also simply ignore logout. Users should therefore not assume that logging out of one application logged them out everywhere; closing the browser is often the more reliable end of an SSO session.

Go deeper:

• OASIS: SAML V2.0 Technical Overview — section 5.3 walks through SP-initiated logout with multiple SPs.
• OASIS: SAML V2.0 Profiles (PDF) — section 4.4 is the normative Single Logout profile.