Single Log-Out (SLO)

What Single Log-Out Does in Federation

Single Log-Out is the federation-side counterpart to single sign-on: it tries to propagate a sign-out event across connected applications so a user is not left logged in somewhere else. That matters because one successful logout at the identity provider does not automatically end every relying-party session.

In practice, SLO depends on session state being shared or invalidated in a coordinated way across applications. When those applications keep their own local session cookies or tokens, logout becomes a distributed control problem rather than a simple button click.

Why SLO Can Fail Quietly

SLO often fails without an obvious error to the user. A logout can appear successful in one browser tab while another application, browser session, or back-channel connection remains valid, which creates a residual access window.

The failure modes are usually procedural rather than exotic: the service does not support the logout profile, the browser blocks front-channel signalling, or an application does not actually destroy its own session when it receives the logout event. The result is not just inconvenience, but a session that can still be replayed or reused if an attacker or another user gains access to the device.

How SLO Relates to Session Security

SLO is really about the lifecycle of session validity across trust boundaries. A federated login can centralise authentication, but session termination remains fragmented unless each participant treats logout as a real security event and not merely a UI action.

That distinction matters for high-risk workflows, shared devices, and long-lived sessions. If a signed-out user can return to a still-authenticated application, the federation layer has not fully enforced the end of access. OpenID Connect Core 1.0 is the best reference point for understanding how federated sign-out is layered on top of authentication rather than replacing application session control.

What Defenders Should Verify

Defenders should treat SLO as a testable control, not an assumption. The key question is whether logout really invalidates sessions everywhere the user was active, including applications that participate only partially or support different logout mechanisms.

Good verification focuses on observable outcomes: whether sessions die after sign-out, whether stale browser state can be reused, and whether the organisation knows which applications implement front-channel or back-channel logout. The surrounding control model aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially for access control, authentication, and auditability expectations.

Risk and Threat Considerations

When SLO is incomplete, the main risk is stale session reuse after the user believes access has ended. That can expose confidential data, preserve access to administrative functions, or let a stolen browser session remain useful after sign-out.

Failure mechanism: The identity provider may end its own session while one or more relying parties keep local sessions alive, or logout signalling may never reach every application.

Impact: An attacker, or even the same user on a shared device, may continue using an active session after logout, which undermines the trust boundary that federation is supposed to enforce.

Practitioner Guidance

What to watch for: Validate SLO as part of release testing, not only sign-in. If a service supports federation but cannot reliably terminate sessions, treat that as a security gap and document the exception explicitly.

Practitioner takeaway: The security value of SLO is only real when logout is enforced at both the federation layer and the application session layer.

Related resources from NHI Mgmt Group

• Who is accountable if a filtered log later turns out to contain an attack signal?
• Who is accountable for deciding whether vaults should log users out instead of only locking them?
• What breaks when organisations can only log out a user from one application after suspicious activity is detected?
• Why do log volumes and telemetry ingest costs spiral out of control in multi-region environments?