LDAPWiki: OpenID Connect Front-Channel Logout

Overview#

OpenID Connect Front-Channel Logout specification defines a logout mechanism that uses Front-channel communication to communicate logout requests from the OpenID Connect Provider to Relying Parties via the User-agent

Other protocols have used HTTP GETs to Relying Party URLs that clear login state to achieve this. This specification does the same thing. OpenID Connect Front-Channel Logout also reuses the Relying Party-initiated logout functionality specified in Section 5 of OpenID Connect Session Management 1.0 (RP-Initiated Logout).

Relying Party Logout Functionality#

Relying Parties supporting HTTP-based logout MUST register a logout URI with the OP as part of their client registration. The domain, port, and scheme of this URL MUST be the same as that of a registered redirect_uri value.

The logout URI MUST be an absolute URI as defined by Section 4.3 of RFC 3986. The logout URI MAY include an application/x-www-form-urlencoded formatted query component, per Section 3.4 of RFC 3986, which MUST be retained when adding additional query parameters. The logout URI MUST NOT include a URI Fragment Identifiers component.

The OpenID Connect Provider renders <iframe src="frontchannel_logout_uri"> in a page with the registered logout URI as the source to trigger the logout actions by the Relying Party. Upon receiving a request to render the logout URI in an iframe, the Relying Party clears state associated with the logged-in session, including any cookies and HTML5 local storage.

The OpenID Connect Provider MAY add these URI Query parameters when rendering the logout URI, and if either is included, both MUST be:

iss - Issuer Identifier for the OpenID Connect Provider issuing the front-channel logout request.
sid - Identifier for the Session.

The Relying Party's response SHOULD include Cache-Control directives keeping the response from being cached to prevent cached responses from interfering with future logout requests. It is RECOMMENDED that these directives be used:

Cache-Control: no-cache, no-store
Pragma: no-cache

In the case that the Relying Party is also an OP serving as an Identity Provider (IDP) to downstream logged-in sessions, it is desirable for the logout request to the Relying Party to likewise trigger downstream logout requests. This is achieved by having the Relying Party serve content in the iframe that contains logout requests to the downstream sessions, which themselves are nested iframes rendering the downstream logout URIs.

If the Relying Party supports OpenID Connect Dynamic Client Registration 1.0 OpenID.Registration, the Relying Party uses this metadata value to register the logout URI:

frontchannel_logout_uri OPTIONAL Relying Party URL that will cause the Relying Party to log itself out when rendered in an iframe by the OpenID Connect Provider. An iss (issuer) query parameter and a sid (session ID) query parameter MAY be included by the OpenID Connect Provider to enable the Relying Party to validate the request and to determine which of the potentially multiple sessions is to be logged out; if either is included, both MUST be.

It SHOULD also register this related metadata value:

frontchannel_logout_session_required - OPTIONAL - Boolean value specifying whether the Relying Party requires that iss (issuer) and sid (session ID) query parameters be included to identify the Relying Party session with the OpenID Connect Provider when the frontchannel_logout_uri is used. If omitted, the default value is false.

More Information#

There might be more information for this subject on one of the following: