Skip to main content

OIDC Single Logout

This article explains OIDC logout aspects and its enhanced implementation by SecureAuth.

Single Logout

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:

  1. User-initiated Single Sign-On (SSO) session logout from the Identity Provider, referred to as RP-initiated Logout

  2. Mechanisms responsible for terminating all related application sessions upon Single Sign-On (SSO) session invalidation, like Back-Channel Logout

RP-initiated 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.

See the sample call to the logout endpoint with SecureAuth 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 post_redirect_uri.

Extended post logout redirect URI logic and restrictions

SecureAuth supports 4 different controls which define the behaviour of the logout:

Client level:

  1. Client can send a query parameter post_redirect_uri in his request to logout endpoint.

  2. 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:

  1. 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.

  2. 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)

OIDC_Single_Logout.svg

  1. post_redirect_uri (if provided) must be https

  2. if strictRedirectEnforcement is enabled then

    • if post_redirect_uri was not provided then generic post logout page is displayed

    • else it must match one of the defined clientPostLogoutRedirectURIs (they MUST be defined)

  3. if strictRedirectEnforcement is disabled and post_redirect_uri was 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 allowedSSOLogoutDomains and ssoPostLogoutURL is set then it will redirect to ssoPostLogoutURL)

  4. if post_redirect_uri was not provided then redirect to ssoPostLogoutURL (if set) or first clientPostLogoutRedirectURIs (if set) or to /$TENANT_ID/$WORKSPACE_ID/app

Back-Channel Logout

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 SecureAuth 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.

In this section: