Single Logout (SLO) is a security feature in authentication systems that enables users to log out from multiple connected applications or services with a single action. Instead of having to log out separately from each application, Single Logout ensures a centralized and coordinated logout process.
OpenID Connect Logout
OpenID Connect Logout is a Single Logout protocol that allows users to securely log out from a web application or identity provider. It builds on the OpenID Connect authentication protocol and extends it to cover the logout process. When a user initiates a logout, the application or identity provider communicates with the relevant parties involved to ensure a consistent and secure log out experience.
Specifications describe both aspects of OIDC logout:
- User-initiated Single Sign-On (SSO) session logout from the Identity Provider, referred to as RP-initiated Logout
- Mechanisms responsible for terminating all related application sessions upon Single Sign-On (SSO) session invalidation, like Back-Channel Logout
RP-initiated Logout (RFC) refers to the logout process
initiated by the Relying Party (RP) in an authentication system.
User initiates logout process by calling
end_session_endpoint that is available in the response of the OIDC Discovery API.
Sample call to the logout endpoint with Cloudentity as an identity provider
curl --location \ --get \ --url "https://$TENANT_ID.$REGION_ID.authz.cloudentity.io/$TENANT_ID/$WORKSPACE_ID/oidc/logout?id_token_hint=id_token_issued_to_client&post_logout_redirect_uri=https://client.com/logged_out"
To find more parameters and their descriptions please refer to RFC
This call results in the user’s Single Sign-On (SSO) session being invalidated on the identity provider and, if specified, the user being redirected to the
Extended post logout redirect URI logic and restrictions
Cloudentity supports 4 different controls which define the behaviour of the logout:
- Client can send a query parameter post_redirect_uri in his request to logout endpoint.
- You can define a list of allowed client’s post logout redirect URIs in the client settings. First one from the list is used if query parameter was not sent.
OAuth server level:
- You can define ssoPostLogoutURL, it’s going to be used if post_redirect_uri is not sent and the client doesn’t have any clientLogoutRedirectURI defined.
- There’s an advanced property in advanced server settings - strict redirect enforcement, defined below.
Here are the rules that apply to
post_redirect_uri in form of diagram (below you will find text representation of it)
post_redirect_uri(if provided) must be https
post_redirect_uriwas not provided then generic post logout page is displayed
- else it must match one of the defined
clientPostLogoutRedirectURIs(they MUST be defined)
post_redirect_uriwas provided then it must match one of the defined
clientPostLogoutRedirectURIs(if defined) - but if not defined then it can either has prefix of token issuer OR be allowed by
allowedSSOLogoutDomains(in that case if not allowed by
ssoPostLogoutURLis set then it will redirect to
post_redirect_uriwas not provided then redirect to
ssoPostLogoutURL(if set) or first
clientPostLogoutRedirectURIs(if set) or to
Once client initiated the logout and session has been terminated on identity provider it is possible to inform related Relying Parties about that fact to log user out from all application where that session has been used to get access. One of the possible mechanisms is Back-Channel Logout.
OIDC Back-channel logout is a mechanism that lets one website or app inform other connected sites or apps that a user has logged out. This happens quietly in the background without bothering the user directly, making sure that their logout is synchronized across multiple services.
In Cloudentity this mechanism is enabled by default. The only thing that needs to be done to start getting notifications about terminated sessions is to provide Relying Party logout URL in client OAuth settings. Request will strictly follow specification (points 2.4 and 2.5). Relying Party should respond with HTTP 200 or 204 as defined in point 2.8 of the specification.