Skip to main content
Identity Authority
Category: Federation & SSO

Single Logout

Also known as: SLO, Single Sign-Out, Single Sign Out
Simply put

Single Logout (SLO) is a feature in federated authentication that lets a user end multiple active sessions with a single logout action, rather than signing out of each application separately. In most deployments it is the counterpart to single sign-on: where SSO establishes sessions across multiple applications from one sign-in, SLO attempts to terminate those sessions together. The user experience is intended to be a single action that logs them out of the identity provider session and connected applications.

Formal definition

Single Logout (SLO) is a session-termination capability in federated authentication that propagates a logout request across the identity provider and the relying parties or service providers that share sessions established through single sign-on. In SAML 2.0, SLO is defined by the Single Logout Protocol, in which a logout can be initiated by an IdP or SP and logout messages are exchanged to invalidate the participating sessions; an OASIS extension, the SAML V2.0 Asynchronous Single Logout Profile Extension, allows the initiator to indicate that it does not expect a response. SLO addresses session lifecycle at logout time and is distinct from the identification and authentication steps that establish sessions; note that its scope covers session termination signaling and not authorization decisions. Behavior varies by deployment and vendor: for example, when multiple sessions are present an IdP may require session selection, and depending on configuration and profile (front-channel vs. back-channel binding), not all participating relying parties are guaranteed to receive or honor the logout, so complete termination across every session cannot be assumed in all deployments. The exact bindings, message flows, and whether logout is best-effort or acknowledged depend on the standard profile and product implementation in use.

Why it matters

Single Sign-On solves the friction of authenticating to many applications from one sign-in, but it also creates a hidden liability: once a user has active sessions across multiple relying parties, closing a browser tab or logging out of a single application does not necessarily end the others. Single Logout (SLO) exists to close that gap by propagating a logout request across the identity provider and the participating relying parties, so that a single logout action attempts to terminate the sessions that SSO established together. Without a working SLO flow, sessions can persist on applications the user believes they have left, which is particularly consequential on shared or kiosk devices and in high-assurance environments.

The practical challenge is that SLO is harder to guarantee than SSO. Depending on the standard profile and binding in use, for example front-channel versus back-channel in SAML 2.0, and on how each relying party is configured, not all participants are guaranteed to receive or honor the logout message. This means SLO is often best-effort rather than a hard guarantee of complete termination across every session. Security architects should treat 'the user clicked logout' and 'every session was actually invalidated' as distinct outcomes, and design and test accordingly rather than assuming a single logout action fully closes the federation.

Who it's relevant to

Security architects
Architects designing federated SSO must decide whether and how to implement SLO, and must account for the fact that complete termination across every relying party cannot be assumed in all deployments. Choices around SAML bindings (front-channel vs. back-channel) and profiles directly affect whether logout is best-effort or acknowledged, which matters most on shared devices and in high-assurance contexts.
IAM engineers
Engineers configuring identity providers and service providers are responsible for the message flows that make SLO work, including how the IdP handles multiple active sessions (which may require session selection) versus a single session (which may proceed automatically). They also need to verify that each participating relying party is configured to receive and honor logout requests.
System administrators
Administrators operating platforms such as identity providers and connected applications manage the day-to-day behavior of logout across the federation. They should validate that a single logout action produces the intended outcome across configured apps rather than assuming it does, and troubleshoot cases where sessions persist after logout.
Compliance officers
Where session termination is part of access control or data protection obligations, compliance leads should understand that SLO signaling and actual session invalidation are distinct, and that the guarantee level depends on profile and vendor implementation. This affects how confidently 'logged out' can be asserted during audits or incident review.

Inside SLO

SLO Profile (SAML 2.0)
In SAML 2.0, Single Logout is defined as a distinct profile that specifies how a logout request initiated at one participant (identity provider or service provider) is propagated to other participants in a federation session. It relies on the same bindings (such as HTTP-Redirect, HTTP-POST, or SOAP) used elsewhere in SAML.
LogoutRequest and LogoutResponse messages
The SAML SLO exchange typically uses LogoutRequest and LogoutResponse messages. These identify the session (often via a SessionIndex and the subject's NameID) so that participants can terminate the correct session rather than all sessions for a principal.
IdP-initiated vs SP-initiated logout
SLO can begin at the identity provider or at a service provider. In IdP-initiated flows the IdP notifies each participating SP; in SP-initiated flows the SP sends the logout to the IdP, which then coordinates termination across other SPs. Behavior depends on the profile and deployment configuration.
Front-channel and back-channel propagation
Logout propagation may occur via front-channel (browser redirects through each participant) or back-channel (direct server-to-server calls such as SOAP). Front-channel depends on the user agent being available; back-channel does not, but requires reachable endpoints between parties.
OIDC logout mechanisms
OpenID Connect defines related logout capabilities in separate specifications, including RP-Initiated Logout, Front-Channel Logout, and Back-Channel Logout. These are distinct specifications rather than a single unified SLO profile, and support varies by provider and library.
Session and token termination scope
SLO addresses termination of established sessions at participating relying parties. Whether previously issued tokens (for example access tokens or refresh tokens) are also invalidated depends on the implementation, since a signed self-contained token may remain valid until expiry unless additional revocation is enforced.

Common questions

Answers to the questions practitioners most commonly ask about SLO.

Does Single Logout (SLO) reliably terminate all of a user's active sessions everywhere?
Not necessarily. SLO is designed to propagate a logout request from the identity provider to the service providers (or vice versa) that participated in a federated session, but its effectiveness depends heavily on deployment. In practice, session termination at each relying party is best-effort: some participants may not implement the logout profile, may be unreachable, or may only clear their local session without invalidating tokens already issued. Depending on configuration, front-channel SLO can fail silently if a browser cannot reach every participant, and back-channel SLO depends on each service provider honoring the request. Treat SLO as a mechanism that attempts coordinated logout across federated sessions rather than a guarantee of universal session termination.
Is logging out via SLO the same as revoking a user's OAuth 2.0 or OIDC tokens?
No. SLO addresses federated session termination, typically at the browser and session level, while token revocation is a separate concern. In OAuth 2.0 and OpenID Connect deployments, access tokens are often self-contained and may remain valid until they expire, regardless of whether an SLO flow has run. Ending a session does not by itself invalidate already-issued access or refresh tokens unless the deployment also performs token revocation or relies on short token lifetimes and introspection. SLO and token revocation should be considered complementary controls rather than equivalent.
What is the difference between front-channel and back-channel SLO, and when is each used?
Front-channel SLO typically relies on the user's browser to relay logout messages to each participating party, often through a sequence of redirects or embedded requests. Back-channel SLO uses direct server-to-server communication between the identity provider and service providers, without depending on the browser. Front-channel approaches can be simpler to deploy but are fragile if the browser closes, blocks third-party requests, or cannot reach a participant. Back-channel approaches are generally more robust for reaching all participants but require reachable endpoints and correct session-to-identifier mapping. The choice depends on the standard profile in use and the network topology of your participants.
How does an identity provider know which sessions to terminate during SLO?
This typically relies on session-tracking identifiers established during login. In SAML 2.0, the SessionIndex issued at authentication is commonly used to correlate a logout request with the specific session at each service provider. In OpenID Connect logout profiles, a session identifier claim (such as a sid) may be used similarly. The identity provider must maintain a record of which service providers participated in a given session so it can direct logout messages appropriately. If this session state is not tracked or is lost, targeted SLO may be incomplete or fail.
What failure modes should we plan for when implementing SLO?
Common failure modes include participants that do not support the logout profile, unreachable back-channel endpoints, browser behavior that interrupts front-channel redirect chains, and mismatched or missing session identifiers. Depending on configuration, a logout may partially succeed, leaving some sessions active while the user believes they are fully logged out. It is prudent to define expected behavior when a participant cannot be reached, decide whether SLO should proceed on a best-effort basis, and consider compensating controls such as short session and token lifetimes. Logging and monitoring of SLO outcomes help identify participants that consistently fail to honor logout requests.
How can we make session termination more reliable when SLO alone is insufficient?
Because SLO is best-effort and does not inherently revoke self-contained tokens, many deployments combine it with additional controls. These commonly include shorter session and token lifetimes to bound the window of continued access, refresh token revocation, and token introspection so that relying parties check current validity rather than trusting a token until expiry. The appropriate combination depends on your protocol profile, vendor capabilities, and risk tolerance. SLO should be viewed as one layer of a broader session and token lifecycle strategy rather than a complete solution on its own.

Common misconceptions

SLO reliably logs the user out of every application in the federation.
In most deployments SLO is best-effort. Front-channel logout depends on the browser successfully reaching each participant, and back-channel logout depends on endpoints being reachable and correctly implemented. Partial failures are common, so complete termination across all participants is not guaranteed.
Ending an SSO session automatically invalidates all issued tokens.
Terminating a session is not the same as revoking tokens. A signed, self-contained token (such as a JWT access token) typically remains valid until it expires unless the deployment adds explicit revocation or short lifetimes, because signing establishes integrity, not session state.
SAML SLO and OIDC logout are the same mechanism.
SAML 2.0 defines a dedicated Single Logout profile, while OpenID Connect defines several separate logout specifications (RP-Initiated, Front-Channel, and Back-Channel Logout). They are related in intent but differ in message flows, transport, and support, and should not be treated as interchangeable.

Best practices

Decide between front-channel and back-channel propagation based on your reliability needs; use back-channel where available for logout that does not depend on the user's browser, and treat front-channel logout as best-effort.
Do not rely on SLO alone to revoke access; pair session termination with short token lifetimes and, where supported, explicit token revocation so that self-contained tokens do not remain usable after logout.
Confirm which logout specification each participant supports (for example the SAML 2.0 SLO profile or a specific OIDC logout spec) before assuming interoperability, since support varies by vendor and library.
Ensure LogoutRequest messages carry the correct session identifiers (such as SessionIndex and NameID in SAML) so that the intended session is terminated rather than an incorrect or overly broad set of sessions.
Design for partial-failure handling and monitoring, logging which participants acknowledged logout so operators can detect and remediate sessions that were not successfully terminated.
Validate logout endpoints, bindings, and configured URLs across all participants during onboarding and after changes, since misconfigured endpoints are a common cause of incomplete propagation.
Promotional banner for the Pentest Readiness checklist download