What is Single Logout and why is there such limited support for it?

Most developers are familiar with Single Sign-On (SSO): log in once, and get access to multiple applications.

Single Logout (SLO) is the opposite of that. It allows users to sign out of every application they are logged into with a single action, a feature that sounds as handy as SSO itself.

SLO ensures that all active sessions are closed at once and that none remain open and potentially vulnerable, yet it's not nearly as widely adopted. Why is that?

In this article, we’ll shine a light on this question by exploring what single logout is, its benefits, and why it has such limited support.

Understanding Single Logout

Before diving into Single Logout (SLO), it is important to understand what Federated Identity Management (FIM) is.

FIM is a system that enables users to access multiple applications across different organizations using a single set of credentials. 

SSO also fits within the broader model of FIM, but there is a key difference. SSO is designed to authenticate a single credential across various systems within a single organization, while FIM systems offer single access to a number of applications across various organizations.

Within FIM, SLO is another feature that allows users to terminate multiple authentication sessions through a single logout action. It is essentially the reverse of SSO.

The mechanics of SLO vary based on the underlying authentication protocols and platforms, such as SAML (Security Assertion Markup Language) and OpenID Connect (OIDC).

Single Logout with SAML

The SAML SLO process can be initiated by either the Identity Provider (IdP) or an Service Provider (SP). It's the responsibility of the SLO initiator (whether a SP or the IdP) to inform the user whether the logout was successful across all systems.

SP-Initiated Single Logout

1. The user clicks the logout button with the SP’s app.
2. The SP terminates the user's sessions.
3. The SP redirects the user with a LogoutRequest to the IdP that includes the name ID (unique identifier) of the user being logged out.
4. Once the IdP receives the logout request, it redirects the user with a logout request to each SP with a known-current session, one-by-one waiting for each logout response.
5. Each SP validates the logout request, terminates the user session on their end then, redirects the user back to the IdP with a LogoutResponse.
6. After receiving all the LogoutResponse messages from the SPs the IdP redirects the user with a final logout response back to the initiating SP, which also ends its session with the user. This response includes a status code indicating whether the logout process was successfully completed.

IdP-Initiated Single Logout

1. The logout process is initiated directly at the IdP, perhaps through a user interface provided by the IdP.
2. The IdP redirects the user with a  LogoutRequest message to all SPs where the user has active sessions, one-by-one.
3. Similar to the SP-initiated process, each SP terminates the user's session and sends a LogoutResponse back to the IdP.
4. The IdP, upon receiving successful logout responses from all SPs, then terminates its own session for the user.

Single Logout with OpenID Connect

OpenID Connect defines more than one logout mechanisms, since the session information can reside either in the frontend (e.g., in a cookie), or in the backend (e.g., stored in a database).

Front-Channel Logout

The OpenID Connect Front-Channel Logout 1.0 specification defines a logout mechanism that uses front-channel communication via the user agent (e.g., the browser). It uses HTTP requests to other applications' logout URLs that clear login state. The flow looks like this:

1. User chooses to logout.
2. The application ends a logout request to the IdP.
3. The IdP notifies all other applications or services that the user has an active session with. This is usually done through the user's browser using JavaScript.
4. The user's browser is instructed to redirect to the logout endpoints of the other applications, while carrying information about the user's logout status. This redirection is often referred to as the "front channel".
5. Each application that receives the logout request processes the request and logs the user out locally. This typically involves clearing session cookies, destroying user sessions, and performing any other necessary cleanup.
6. After all applications have completed their logout processes, the user's browser is redirected back to a landing page (e.g., a login page).

Back-Channel Logout

The OpenID Connect Back-Channel Logout 1.0 specification defines a server-to-server communication for the logout request. The flow looks like this:

1. User chooses to logout.
2. The application sends a logout request to the IdP.
3. The IdP identifies all other applications or services where the user has an active session and sends them a logout notification using a secure, back-channel communication method.
4. Each application logs the user out locally. This typically involves revoking access and refresh tokens, and performing any other necessary cleanup.
5. Once the user is logged out from all apps and services, the IdP may send a confirmation back to the initiating application.

Why is SLO important?

SLO is important mainly in environments where multiple users share the same workstation. In these cases, SLO makes sure when one user logs out once, they’re logged out everywhere, preventing the next user from accidentally accessing previous sessions with sensitive information. 

It may also be important for compliance reasons. Some security standards mandate it.

Pain points of SLO

In an ideal SLO setup, when a user decides to log out from one application, it should trigger a logout from all other applications where the user is logged in. 

This process requires coordination between the IdP and all participating SPs to ensure that logout requests and notifications are properly managed and synchronized.

Unfortunately, there are usually some difficulties, and that's why SLO has such limited support.

Technical complexities

SAML 2 defines two ways of transporting log out requests and responses: 

1. Front-channel bindings: This is through the browser via HTTP POST or Redirect.
2. Back-channel bindings: This is via direct IdP/SP SOAP messages.

When an IdP uses front-channel binding, it gives complete control to the service providers iteratively. During a logout request, this method directs the user's browser to each application where the user is logged in, one by one. Each SP must successfully receive and process this logout request for the process to work.

An SP, however, might become unresponsive. This could be due to various reasons, such as network disruptions, server overloads, maintenance or failures, and stringent security configurations or firewalls that mistakenly block SAML logout requests.

When this happens, the process breaks down, and the remaining SPs with active sessions don’t receive logout requests. Worse still, neither the IdP, nor the SP provides feedback to the user, and the user will be presented with a generic HTTP error without further information.

Some SLO implementations use iframes as a workaround. When a user attempts to log out, iframes pointing to the logout endpoint of each application are rendered. This method isolates each SP's logout request within a separate iframe, effectively containing any errors and preventing them from disrupting the entire logout process. However, there's no way to confirm whether the iframe itself is rendered correctly.

Additionally, front-channel SLO requires setting session cookies in browsers which can only be destroyed by the application (or domain) that set them. In scenarios where an admin wants to terminate user sessions across various SPs from the IdP, they face a restriction as they cannot directly destroy session cookies because of the domain restriction on cookies.

This means that while the IdP can initiate a logout process and inform all relevant SPs to log the user out, it cannot directly ensure or enforce that all session cookies on the user's browser are deleted.

In back channel binding the IdP and SPs send logout requests directly without using the user's browser which prevents most of the problems with front channel logout. It, however, isn’t widely supported.

Lack of standardization across SPs

In SLO implementations, SPs don’t communicate with each other directly but through the IdPs. The IdP sends logout requests to each SP individually. If any SP fails to process the logout request, the other SPs are typically not notified of this failure, leading to an incomplete SLO process.

Consider a user who’s logged in to apps A, B, and C. When the user logs out from app C, there is no direct way for app C to inform apps A and B that the user has logged out. As a result, while app C ends the user’s session, apps A and B may unknowingly keep their sessions active.

The OpenID Shared Signals Framework addresses this standardization issue. Rather than expecting all SPs to revoke user sessions, with this framework, SPs are instead notified of various signals which they can respond to, as is appropriate to their use case. 

For example, if an app receives a signal from Microsoft Entra that jane@example has 3 failed login attempts, it might kill the session for jane@example. If it’s a banking app, it might require jane@example to do an SSO the next time they try to log in.

User experience

One of the challenges with SLO is ensuring immediate feedback to users about the status of their logouts across all SPs. Once the user clicks the logout button, do they know they’re not being logged out from only that application but all their other active sessions? 

In theory, SPs could use a coordinated logout UI component to signal a universal logout. However, this requires users to recognize what this UI means, and it also depends on all participating SPs agreeing to use a single UI component, which is highly unlikely due to varying brand guidelines and design preferences.

Furthermore, some apps use an image as the logout UI component. These could be icons or buttons that visually depict actions like "logout" or "sign out.” While they are intuitive, they’re not accessible, particularly for users who are visually impaired or who rely on screen readers. This problem can be solved using descriptive alt text that provides the same function and meaning as the image.

Another issue is during SP-initiated SLO, while it’s the responsibility of the SP to indicate to the user if the logout was successful, the IdP typically sends back minimal information — usually just a status code indicating general outcomes like success, partial logout, or request denied, without detailed explanations. 

This lack of detail makes it difficult for SPs to provide specific feedback to users about what went wrong if the logout process fails. Without enough information, a user can assume the logout was a success and leave their session active and open for attack.

UX implications

If SLO is supported, then should the SP display both SLO and application-level logout? Or should it only show the SLO option? Hubspot, for example, only shows application-level logout.

Lack of standardization among IdPs

SLO generally lacks wide support, so there are many edge cases, and each IdP will treat them differently. The lack of standardization means that, as a developer, you can’t always predict how a given IdP will behave. This unpredictability makes it difficult to design a single SLO solution that works seamlessly across all your customers' IdPs.

The bottom line

Single Logout (SLO) is designed to log users out of all their active sessions across different apps with just one click. Ideally, this means greater convenience and enhanced security, as it minimizes the risk of leaving sessions that could be hijacked open. 

However, the real-world implementation of SLO often runs into a few snags, like issues from front-channel bindings, lack of standardization across SPs, and user experience issues that can make that one-click logout a bit more of a hit or miss.

That said, SLO can still help reduce the number of orphaned sessions, just keep in mind that it doesn't guarantee that none will slip through the cracks.