Single Logout (SLO)

What is Single Logout?

Single Logout (SLO) is single sign-on’s mirror image: one logout terminates the user’s sessions across every application that shared the SSO session. The need is obvious — a departing employee, a stolen laptop, a shared kiosk — and the implementation is notoriously messy, because login is a moment but sessions are a diaspora: after SSO, each application typically minted its own local session (cookie, JWT) that outlives anything the identity provider does.

Why it’s hard in practice

The protocols exist — SAML Single Logout, OIDC front-channel and back-channel logout — and each disappoints differently. Front-channel logout loads hidden iframes to every app’s logout URL in the user’s browser: one slow or broken app, blocked third-party cookies (i.e., modern browsers), or a closed tab and the chain silently fails. Back-channel logout has the IdP call each app server-to-server — far more reliable, but every application must implement the endpoint and be able to kill sessions server-side, which stateless-JWT architectures by design cannot do for already-issued tokens. Partial logout is the common real-world outcome, and it fails silently: the user believes they’re logged out everywhere.

What robust deployments actually do

Short local session lifetimes with frequent re-validation against the IdP (so revocation propagates within minutes even without explicit SLO), back-channel logout for the applications that matter most, and — for high-stakes events like terminations — session-store revocation at the IdP plus token-introspection checks rather than trust in logout choreography.

What people get wrong

• Statelessness versus SLO blindness: choosing pure JWTs and promising instant global logout — the two are architecturally incompatible without short TTLs or introspection.
• Testing login flows only — SLO breaks quietly as apps are added; audit it like the security control it is.
• Confusing this SLO with Service Level Objectives — identity’s unluckiest acronym collision.

Primary source: OpenID Connect Back-Channel Logout 1.0 specification

Why SLO Is Harder Than It Sounds

Implementing single logout reliably is technically more challenging than single sign-on, because it requires the identity provider to notify every connected service provider that a session has ended — and unlike login, where the user is actively present and can be redirected through each step, logout notifications often need to happen via backend-to-backend calls that can fail silently (a service provider’s logout endpoint being temporarily unreachable, for example) without the user ever knowing their session wasn’t actually terminated everywhere. This is why many real-world SSO implementations support single sign-on robustly but implement single logout only partially or not at all, an accepted security tradeoff given the genuine difficulty of guaranteeing SLO’s reliability across every connected service.