SAML Single Logout (SLO)
Decide who initiates logout and how to close all sessions. This guide focuses on practical SLO flow and operations.
🔁 Basic SLO Flow
SLO starts when either the IdP or SP sends a LogoutRequest.
Typical steps
- ➡️ User clicks “logout” on an SP or IdP.
- ➡️ A SAML LogoutRequest is sent to the other party.
- ➡️ Validate the LogoutResponse protection and Status to distinguish completion from partial failure.
- ➡️ If multiple SPs exist, LogoutRequests may cascade to each.
🧭 One-sided vs Mutual Triggers
Choose who owns the trigger and align user experience.
Design points
- ✅ IdP-initiated: Easy to log out everywhere at once, but needs consistent SP setup.
- ✅ SP-initiated: Useful when logging out of one app should also close others.
- ✅ Define message ordering and retry handling so either trigger stays consistent.
🛡️ Session Handling and Browser Considerations
Deleting cookies alone does not invalidate server sessions. Map the authenticated LogoutRequest NameID and SessionIndex, when supplied, to the target sessions. Validate message integrity, sender and response InResponseTo.
Operational tips
- 🔍 Terminate both IdP and SP sessions.
- 🔍 Third-party cookie blocking can break iframe-based SLO; plan fallbacks.
- 🔍 Show a notice if full logout could not be confirmed.
🧯 Handling Failures
Sessions can remain at other SPs after a failure. Check the result rather than reporting that every service is logged out. SAML Core defines the second-level PartialLogout status when not all participants confirm logout.
Common issues and mitigations
- ⚠️ LogoutRequest not delivered to some SPs: add retry/timeout handling.
- ⚠️ Response validation fails: signature requirements differ across IdP/SP.
- ⚠️ Closing a browser does not guarantee server-side session termination. Check remaining sessions and offer individual logout where needed.