Client Side OAuth Single Logout

DXA supports the following OpenID Connect logout specifications when acting as an OpenId Relying Party (RP):

OAuth client logout endpoints

The DXA OAuth client provides the following logout endpoints:

  • /<oauth-client-context-path>/logout: Initiates the OpenID Connect RP-Initiated Logout flow.

  • /<oauth-client-context-path>/frontchannel_logout: Receives front-channel logout notifications as specified in the OpenID Connect Front-Channel Logout specification.

  • /<oauth-client-context-path>/backchannel_logout: Receives back-channel logout notifications as specified in the OpenID Connect Back-Channel Logout specification.

DXA OAuth client functionality in OpenID Connect Single Logout

When acting as an OpenID Connect RP, the DXA OAuth client supports the following functionality:

  • Initiating RP-Initiated Logout at the OP logout endpoint:

    • When the logout endpoint is accessed, DXA resolves the DXA session from the session cookie. If the session was created using an OpenID Connect ID token, the upstream OP(s) are identified and the RP-Initiated logout flow is initiated (depending on the Single Logout configuration).

    • If DXA acts as an identity proxy, downstream clients are also notified of the logout as described in OAuth Single Logout.

  • Receiving front-channel logout notifications:

    • When a front-channel logout notification is received at the frontchannel_logout endpoint, DXA attempts to associate the notification with an existing DXA session using the sid and iss claims in the parameters. If no parameters are present, DXA tries to resolve the session from the session cookie; however, this method is less reliable as browsers may block cookies in iframes.

    • If a matching session is found, DXA invalidates the session and tokens issued during the session (depending on configuration) and attempts to remove the session cookie from the browser.

    • DXA cannot initiate further logout notifications upstream to other OPs if multiple OPs were used to create the session. If downstream clients are connected to DXA as an identity proxy, those clients are notified of the logout using either front-channel or back-channel notifications.

  • Receiving back-channel logout notifications:

    • When a back-channel logout notification is received at the backchannel_logout endpoint, DXA validates the logout token. If valid, DXA attempts to associate the notification with an existing DXA session using the sid and iss claims in the logout token. If no sid claim is present, the sub claim is used to find logout the session; however,with this method, all the sessions created with the same subject and the issuer are logged out.

    • If a matching session is found, DXA invalidates the session and tokens issued during the session (depending on configuration). The session cookie itself cannot be removed from the browser as there is no browser interaction in back-channel logout.

    • If downstream clients are connected to DXA as an identity proxy, those clients are notified of the logout only if they support back-channel logout. If they do not support back-channel logout, they will be logged out locally (their tokens will be invalidated on the DXA side).

DXA OAuth client does not support encrypted logout tokens in backchannel logout requests for now, as it does not support encrypted OpenID tokens also.

Configuration of OAuth client single logout

The configuration for OAuth client single logout is done in: Configuration → Federation → OAuth → Client endpoints → <your OAuth client>.

Enabling Logout Endpoints

By default, all OAuth Client logout endpoints are disabled. To enable the endpoints, select the supported logout endpoints in the Enabled logout endpoints configuration.

It is important to register the front-channel and back-channel logout URIs with the upstream OPs to receive logout notifications from the OP.

Referencing Single Logout configuration

Another important step is to create a reference to a Single Logout configuration. This configuration defines the single logout process that will be used for all logouts initiated at this OAuth Client endpoint, including logouts initiated at this endpoint with RP-Initiated Logout and logouts initiated upstream at an OP that notify this client with front-channel or back-channel notifications.

General details about Single Logout configuration are described in Single Logout.

For the OAuth Client, the relevant SLO peers are of type "OAuth client SLO peers". These include a reference to the OAuth client configuration and OAuth server metadata. This determines which OPs are included in the RP-Initiated logout process when the /logout endpoint is accessed. During front-channel and back-channel notifications, the RP does NOT use this list as it cannot initiate further logout notifications upstream.

If the DXA server acts as an inbound proxy, the OAuth server SLO peers will be used to determine which downstream tokens to log out. If any consent SLO peers are defined for downstream clients, the "Do logout when notified when consent needed" configuration is applied. If enabled, tokens and/or sessions requiring consent will be logged out without user interaction; if disabled, those tokens will remain active.

RP initiated logout behavior

When a logged-in user accesses the OAuth client logout endpoint at the /logout path, the following steps are performed:

  1. DXA resolves the DXA session from the session cookie. If no session is found, the user is redirected to the default post-logout redirect URI if defined in the related Single Logout configuration.

  2. If a session is found and tokens were issued during the session, they are invalidated according to the logout peer configurations as described in OAuth Single Logout.

  3. The user may be prompted for consent if any clients in the session are defined as consent SLO peers or if any upstream OPs require consent for logout.

  4. Front-channel and back-channel logout notifications are sent to the relevant OPs, and the DXA session is invalidated.

  5. If there are upstream OPs to log out, the OpenID RP-Initiated logout flow is initiated by redirecting the user to the OP logout endpoint, including the id_token_hint parameter with the ID token issued by the OP.

  6. After logout, the user is redirected either by the OP to the default post-logout redirect URI defined in the Single Logout configuration or back to the OAuth client /logout endpoint. The same applies if there are no upstream OPs to log out.

As the RP initiated logout uses cookie to resolve the session, it is important to have the same cookie configuration in the Policy Enforcement Point (PEP) assigned to the OAuth client endpoint, as the one used when creating the session (This will be the case if the session was created when accessing the same OAuth client endpoint).
It is important to register the post logout redirect URIs at the upstream OPs, to be redirected back to DXA after logout. This should be the /logout endpoint of the OAuth client, as well as the default post logout redirect URI defined in the single logout configuration.