Single Logout (SLO) is the idea that when a user signs out of one application, their session should be ended across other applications that participate in the same sign-in ecosystem.
In practice, SLO is hard because “logout” is not a single thing:
- a browser session (cookies)
- an IdP session
- one or more SP/app sessions
- one or more API tokens (access/refresh)
This guide explains the two main approaches—front-channel and back-channel—and how to decide what you actually need.
Key concepts
- IdP session vs app session: ending one doesn’t automatically end the other.
- Global vs local logout:
- Local logout ends the session for one app.
- Global logout tries to end sessions for the whole federation.
- Front-channel vs back-channel:
- Front-channel uses the user’s browser to “fan out” logout.
- Back-channel uses server-to-server calls.
Front-channel logout (browser-mediated)
Front-channel logout means the logout propagation happens by navigating the user’s browser to other parties.
Typical patterns:
- Redirect-based logout: user clicks logout → app redirects to IdP logout endpoint → IdP redirects (or iframes) to other apps.
- Hidden iframe logout: IdP returns a page containing multiple iframes, each calling a participant’s logout URL.
Pros
- Works even when apps can’t be reached directly from the IdP over the network (because the browser can reach them).
- Can leverage existing SSO session cookies.
Cons / pitfalls
- Reliability: if the browser blocks third-party cookies, iframes, or tracking protection, SLO can fail silently.
- User experience: can be slow or “flash” multiple redirects.
- Partial logout is common: you end up with a “best effort” logout.
- Hard to prove: you rarely get strong confirmation that every downstream session was terminated.
Back-channel logout (server-to-server)
Back-channel logout means the IdP (or coordinating component) notifies apps via direct HTTP calls.
Typical patterns:
- IdP sends a signed logout message/notification to each relying party.
- Apps validate the message, locate sessions for the subject/session, and revoke them.
Pros
- More deterministic than relying on browser behavior.
- Better for service-to-service session termination and systems without a browser.
- Easier to integrate with token revocation and internal session stores.
Cons / pitfalls
- Requires network reachability and authentication between parties.
- Requires each app to implement robust “find and kill sessions” logic.
- Still can’t guarantee immediate logout if the app is down or if there’s retry/backoff.
What “good” SLO looks like
In modern IAM, you often aim for:
- Local logout: clear app session cookie + invalidate server session record.
- IdP logout: end the IdP session (so re-auth is required next time).
- Token strategy: short-lived access tokens + refresh token revocation/rotation.
- Continuous controls: risk-based session controls (device posture, CAE where supported).
SLO is often less about “instant global logout” and more about bounded session lifetime + fast revocation.
Decision guide
Use SLO when:
- Users frequently sign into multiple apps and you have a strong policy reason to end sessions across them (shared kiosks, regulated environments).
Skip (or de-emphasize) SLO when:
- Apps use short-lived tokens and re-auth frequently anyway.
- Your environment has many third-party SaaS apps where you can’t reliably terminate sessions.
Common pitfalls
- Treating logout as a security control instead of a UX feature.
- Not defining what “logout complete” means.
- Ignoring refresh tokens (logout without refresh revocation is a weak guarantee).