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.
- ➡️ A LogoutResponse is returned to confirm session termination.
- ➡️ 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 may not be enough; end sessions explicitly on both IdP and SP.
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
Because multiple systems are involved, having a recovery plan for SLO failures is important.
Common issues and mitigations
- ⚠️ LogoutRequest not delivered to some SPs: add retry/timeout handling.
- ⚠️ Response validation fails: signature requirements differ across IdP/SP.
- ⚠️ User closed browser: prompt re-login on the next visit if unsure.