Single Logout (SLO)
Single Logout (SLO) is a federated identity session termination feature that logs a user out of all connected applications and sessions across an identity federation with a single logout action.
What is Single Logout (SLO)?
Single Logout (SLO) is a federated identity management capability that enables a user to terminate their authenticated sessions across multiple service providers and the identity provider with a single action. When a user logs out of one application in a federated environment, SLO propagates the logout request to all other applications where the user has active sessions, ensuring comprehensive session termination.
How SLO works in SAML. In a SAML-based identity federation, SLO uses the <LogoutRequest> and <LogoutResponse> message types. When a user initiates logout at a service provider, the SP sends a SAML LogoutRequest to the IdP's SLO endpoint. The IdP then propagates the logout to all other SPs where the user has sessions, either synchronously (waiting for each SP to respond) or asynchronously. Each SP terminates its local session and returns a LogoutResponse. Once all responses are received, the IdP terminates the user's session and sends a final response to the initiating SP.
SLO challenges. While conceptually simple, SLO is notoriously difficult to implement reliably. Challenges include: network failures during logout propagation, SPs that are offline or unreachable, SPs that only support HTTP-POST binding (requiring user interaction), and partial logout states where some sessions are terminated while others persist. Many federations implement best-effort SLO rather than guaranteed SLO to address these practical limitations.
Analogy
Single Logout is like the master key that locks every door in a building at once. If you have entered multiple offices using a badge, pressing the master logout button locks all of them simultaneously instead of forcing you to walk to each door and lock it individually.
Types and Use Cases
- Enterprise federation logout: An employee logs out of their corporate SSO portal, which triggers SLO across all connected SaaS applications (Salesforce, Workday, Office 365) to terminate all sessions simultaneously.
- Government citizen portals: Citizens log out of a government services portal, and SLO terminates sessions across tax filing, healthcare, and benefit management applications in one action.
- Educational institution environments: Students and faculty log out of a university portal, terminating sessions across the LMS, library system, email, and research tools.
- Healthcare provider networks: Clinicians log out of a health information exchange portal, terminating sessions across EHR systems, scheduling, and billing applications to maintain HIPAA compliance.
How it Works
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_a1b2c3d4e5"
Version="2.0"
IssueInstant="2026-06-01T16:00:00Z"
Destination="https://idp.example.com/saml/slo">
<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
user@example.com
</saml:NameID>
<saml:SessionIndex xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
_session_index_abc123
</saml:SessionIndex>
</samlp:LogoutRequest>Single Logout (SLO) vs Single Sign-On (SSO)
Single Logout (SLO)
Single Sign-On (SSO)
Single Logout terminates all federated sessions across applications with one action
while Single Sign-On establishes all federated sessions across applications with one authentication action.
SLO focuses on session termination and security by ensuring no orphaned sessions remain
while SSO focuses on authentication convenience and user experience by reducing login prompts.
SLO propagates logout messages from the IdP to all SPs using SAML LogoutRequest bindings
while SSO propagates authentication assertions from the IdP to SPs using SAML Response bindings.
Best Practices for Single Logout (SLO)
- Implement best-effort SLO rather than requiring guaranteed logout from every SP — handle SP timeouts and failures gracefully without blocking the user's logout experience.
- Use front-channel bindings (HTTP Redirect/POST) for SLO when possible, as backchannel SOAP bindings may not work in all network configurations (especially with firewalls and NAT).
- Always present a logout confirmation screen — show the user which applications were successfully logged out and which (if any) failed, with options to manually terminate remaining sessions.
- Include SLO in your threat model — incomplete SLO can leave sessions active on unattended devices; implement session timeouts and inactivity-based termination as a safety net.
How LoginRadius Powers Single Logout (SLO)
LoginRadius supports SAML Single Logout (SLO) as part of its identity provider capabilities. When a user initiates logout from a LoginRadius-hosted session, the platform sends SAML LogoutRequests to all registered service providers, ensuring comprehensive session termination across the federation. LoginRadius supports both SP-initiated and IdP-initiated SLO flows with configurable timeout handling and detailed audit logging for compliance.
FAQs
SLO implementations typically handle offline SPs by using a best-effort model. If an SP is unreachable, the IdP either marks the logout as incomplete (and reports it to the user) or retries later. Some implementations skip unresponsive SPs and proceed with the logout for reachable ones, logging the failure for audit.
Yes. OpenID Connect provides RP-Initiated Logout and Session Management specifications that implement similar functionality to SAML SLO. The mechanism uses an end_session_endpoint where the RP redirects the user, and the OP logs the user out of all relying parties. OIDC also supports backchannel logout via the backchannel_logout_uri for server-to-server session termination.
LoginRadius supports SAML Single Logout for both SP-initiated and IdP-initiated logout scenarios. When configured, LoginRadius propagates logout requests to all service providers in the federation and terminates the user's session at the LoginRadius IdP. The platform supports both HTTP-Redirect and HTTP-POST bindings for SLO and provides detailed logout audit logs.