Single logout (SLO) is a process that coordinates sign-out across applications sharing an identity provider, ending the sessions included in that logout flow.

A customer may use one sign-in to access a main portal and a separate support application. Each application can create its own session after the identity provider authenticates the customer. SLO provides a way to coordinate the end of those sessions, but its reach depends on the participating systems.

Single logout and local logout

Local logout ends access to one application. If the identity-provider session remains active, returning to that application may start a new session without another credential prompt. The behavior can be convenient on a personal device and confusing on a shared computer.

Single logout extends the request to the identity provider and connected applications according to the federation configuration. The product interface should explain the intended scope. “Sign out of this portal” and “sign out of connected services” create different expectations.

How coordinated sign-out works

SAML defines a single logout profile through which participants exchange logout requests and responses. OpenID Connect provides separate specifications for initiating logout at the provider and notifying applications that sessions should end.

With front-channel logout, messages travel through the browser. Back-channel logout sends a message directly from the identity provider to an application’s logout endpoint. The application validates that message and identifies the sessions it should terminate. Direct notification avoids some browser dependencies, although delivery and correct session mapping still matter.

An application that does not support the selected logout mechanism may keep its local session. An unavailable endpoint can also prevent complete propagation. Teams should test sign-out across actual application combinations, including open tabs and expired sessions, rather than assuming that successful single sign-on proves logout works.

What happens to API access?

Ending a browser session does not necessarily revoke OAuth tokens. An access token may remain usable at an API until expiration or a relevant revocation check rejects it. Refresh-token revocation is another action with its own consequences.

For example, signing out of an insurance portal may end both its web session and the connected claims application’s session. A mobile app authorized separately could remain signed in. That can be the intended policy, provided the customer can understand and control it.

Incident response may require broader action than ordinary sign-out, such as terminating all account sessions and withdrawing affected credentials. SLO is one part of that response, with a defined federation scope.

Frequently asked questions

Does single sign-on automatically include single logout?

No. Applications and identity providers must support and configure the relevant logout mechanisms. Sign-in interoperability alone does not establish coordinated sign-out.

Does single logout always sign out every device?

No. Its scope depends on how the provider and applications identify sessions. An all-device sign-out feature requires explicit support and policy.

Does SLO revoke all access tokens?

Not automatically. Session termination and token revocation are separate controls. APIs may continue accepting an issued token until their validation rules reject it.

Related: Single Sign-On (SSO) · Identity Federation · SAML · OpenID Connect (OIDC) · Identity Provider (IdP) · Session Hijacking