Single logout for OIDC applications

With single logout (SLO), users can log out of all single sign-on applications simultaneously. This feature enhances security by preventing unauthorized access to any lingering session, especially when a device is shared with other persons.

When you implement single logout (SLO) functions, three kinds of sessions exist.

Application Session: Although the application uses the OpenID (OP) to authenticate users, it might track the user that logged in to the application. Typically, an application tracks sessions with a browser cookie. The application is responsible to clear the session during logout.
Authorization Server OpenID provider (OP) Session: An authorization server also maintains a user session and stores it inside a cookie. An authorization server clears the user session during logout, along with the grants and tokens that are related to the user session.
Identity Source Session: Users might sign in with a user session from an identity source. During logout, the user might also want to logout from that user session.

Note: Single logout does not support logout from an identity provider session. It also does not support logout from SAML applications. Although SAML has a similar endpoint to perform IdP-initiated and SP-initiated logout, it is not integrated with OIDC single-logout.

Two mechanisms exist for an authorization server (OP) to notify the application that a logout was triggered, front-channel and back-channel. In both mechanisms, the application registers a logout endpoint that the authorization server calls. This endpoint wraps the code that the application uses to clear its session. Calling the application's logout endpoint is not reliable because IBM® Verify has no obligation to retry or to ensure that the application successfully clears its session. The back-channel logout is the preferred mechanism.

Front-channel logout

A front-channel logout or client-side logout is a method of single logout (SLO) in which the client (usually a web browser) directly communicates with the server to invalidate the user's session. It is typically done by sending a request to the server to delete the session cookie or token. The server then responds to confirm the logout. This method is straightforward and works well for single-domain scenarios. However, it might not be suitable for complex, multi-domain, or multi-protocol environments due to potential issues with cross-origin communication and security. When you use the front-channel mechanism, the authorization server (OP) renders

<iframe
src="frontchannel_logout_uri">

in a page to trigger an HTTP GET call to the application's logout endpoint. The application can request the authorization server to send the session ID (sid) and the issuer (iss) information as extra query parameters. If the application client is created by using dynamic client registration, set frontchannel_logout_session_required client metadata to true. For IBM Verify, when you configure OpenID application in the admin UI, the setting is available at the Sign-on tab. Scroll to the Single Logout Settings section and select the Session Required checkbox. The application can use the information to validate the request and to determine which sessions to log out of. If the sid does not match the current or recent session with the authorization server (OP), the application might ignore the logout request.

Note: OIDC Front-channel Logout recommends the use of an iframe to call the front-channel logout endpoint. Modern browsers by default block third-party cookies to be forwarded in iframe. If the application's domain is different than the authorization server's domain, it does not receive any cookies, which might prevent the application from logging out the user properly. The user would need to configure their browser to allow third-party cookies for the authorization server's domain.

Back-channel logout

A back-channel logout or server-side logout is a method of single logout (SLO) in which the identity provider (IdP) communicates directly with the service provider (SP) to invalidate the user's session. It is typically done through a secure channel that is established between the IdP and SP during the initial authentication process. When you use the back-channel mechanism, the authorization server (n) performs an HTTP POST to the application's logout endpoint through a direct back-channel API. The authorization server issues a logout JWT token that contains the following information.

Claim name	Usage	Description
`iss`	Required	Issuer identifier.
`sub`	Optional	Subject identifier. Must be present when `sid` is not present.
`aud`	Required	Audience or audiences.
`iat`	Required	Issued at time.
`exp`	Required	Expiration time.
`jti`	Required	Unique identifier of the token.
`events`	Required	JSON object that contains the member name http://schemas.openid.net/event/backchannel-logout.
`sid`	Optional	Session identifier. Must be present when `sub` is not present.

The authorization server (OP) uses the same configuration to sign, encrypt, or both the logout JWT token as the ID token.

In an application-relying party (RP) initiated logout scenario, an application triggers the logout by redirecting to the authorization server's end_session_endpoint, which is published in the authorization server's discovery endpoint. The application might send the following request parameters.

Parameter name	Usage	Description
`id_token_hint`	Recommended	The ID Token that the authorization server issued as a hint about the user's authenticated session with the application.
`logout_hint`	Optional	A hint to the authorization server about the user who is logging out.
client_id	Optional	The application's client identifier.
`post_logout_redirect_uri`	Optional	The URI that the application requests that the user's user agent is redirected to after a logout is performed.
`state`	Optional	An opaque value that is used by the application to maintain state between the logout request and the callback to the `post_logout_redirect_uri` endpoint.
`ui_locales`	Optional	The user's preferred languages and scripts for the user interface.

When the id_token_hint is not specified or the ID token does not belong to the current logged in user, the authorization server asks the user whether to clear the authorization server session. Next, similar to the OP-initiated logout scenario, the authorization server finds the list of applications that were signed on with the same authorization server (OP) session. It notifies the applications by using one of the channel logout mechanisms. Then, if the user gives the consent, the authorization server clears its own session. If the post_logout_redirect_uri is specified and can be validated against the client configuration, at the end of the logout process, redirection to that URI is performed. Otherwise, the authorization server displays the logout summary report.

Tip: If you are building a custom-application logout endpoint,

For front-channel logout

Verify expects the application logout endpoint to respond within 3 seconds.

For back-channel logout

Verify expects the endpoint to return 2xx for success and 400 for any errors.
Verify expects the application logout endpoint to respond within 3 seconds.
For faster validation of JWT logout token, the application logout endpoint caches the Verify JWKS endpoint.