SAML single logout: ending every session is harder than starting one

Signing in through SAML is a well-trodden path. Signing out of every application is where integrations go to die.

SAML single logout (SLO) exists to solve it: end the session at the identity provider, and every application that accepted that session should end its own. In practice, it is the least reliable part of most SSO deployments, for reasons that are worth understanding before you promise it to a customer.

The pieces

SAML SLO uses two messages:

• LogoutRequest — "end the session(s) for this user."
• LogoutResponse — "done" (with a status code).

The tricky part is identifying which sessions to end. SAML solves it with the SessionIndex: a value in the assertion's AuthnStatement that identifies the login session at the identity provider. When the SP sends a LogoutRequest, it includes the SessionIndex it received, so the identity provider knows exactly which session to terminate.

Without the SessionIndex, the identity provider can only guess, which usually means "end the session in this browser" — and that is not the same as "end every session".

The two directions

SP-initiated logout. The user signs out of an application. The application sends a LogoutRequest to the identity provider's SingleLogoutService, then the identity provider ends the session and notifies the other applications that participated in it.

IdP-initiated logout. The user signs out of the identity provider — from a portal, or a central "sign out everywhere" button. The identity provider sends LogoutRequests to every application that was part of the session.

Both directions are part of the SAML standard, and both fail in the same places.

Why SLO breaks in practice

1. Third-party cookies. Front-channel logout means loading an image, iframe or redirect in the user's browser for every application. Browsers increasingly block or partition the cookies that make this work, so an application may receive the logout notification but not be able to clear the session it belongs to.

2. Not every application implements it. Plenty of SAML service providers accept logins and ignore logout requests. The identity provider sends the request; nothing happens.

3. Session identity is fragile. Some SPs do not store the SessionIndex, or store one per browser tab, or rotate it. Without the right value, logout becomes "log out this browser, if the user is lucky".

4. Partial logout is invisible. There is no global registry of "all sessions everywhere". An application that did not receive the message keeps working, and the user assumes they are signed out.

5. Clock skew and certificate rotation break logout messages just as they break logins — usually with less monitoring, because logout failures are silent.

What a working implementation looks like

• Store the SessionIndex from each assertion, keyed by user and application.
• Set a SingleLogoutService URL on every application you want to log out, and keep it current.
• Support both bindings (HTTP-Redirect and HTTP-POST) if your applications differ.
• Treat logout as best-effort and always end the local session first. A failed remote logout must not keep the user signed in locally.
• Log every logout attempt with the application and the result, so support can answer "did they really sign out?"
• Combine with short session lifetimes. If sessions expire in hours, a missed logout is a smaller problem.

How Casdoor handles it

Casdoor supports SAML single logout in both directions:

• Each assertion includes a SessionIndex in its AuthnStatement, which identifies the Casdoor session.
• The application metadata announces Casdoor's SingleLogoutService at /api/saml/logout/admin/<application-name>, with the HTTP-Redirect and HTTP-POST bindings.
• When an SP sends a LogoutRequest, Casdoor validates the issuer, the NameID and the application's configured single logout URL, ends the sessions named by the SessionIndex values, and then signs the user out of the other applications in those sessions using OIDC back-channel logout and SAML logout requests.
• When the user signs out of Casdoor, Casdoor sends signed LogoutRequests to the single logout URL of every SAML application that was part of the ended sessions — from the server, not through the browser.

Set SAML single logout URL on the application to the SP's SingleLogoutService URL to enable it.

SLO in OIDC terms

If you are choosing protocols, OIDC has two comparable mechanisms:

• RP-initiated logout — the application redirects to the provider's end-session endpoint with an id_token_hint.
• Back-channel logout — the provider calls the application's server directly with a signed logout token. This avoids the third-party cookie problem entirely, which is why it is the more reliable option.

SAML has no direct equivalent of back-channel logout; the closest pattern is the identity provider sending logout requests server-to-server, which is what Casdoor does for IdP-initiated logout.

What to tell customers

Be precise. "We support SAML single logout" means different things to different buyers. The honest version:

• Logout at the identity provider ends the sessions of applications that support SLO.
• Applications that ignore logout requests keep their sessions until they expire.
• Session lifetimes are the backstop, so make them defensible.

Related reading: set up Casdoor as a SAML IdP, SP-initiated vs IdP-initiated SSO and single logout in Casdoor.