jspωiki
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:

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:

It SHOULD also register this related metadata value:

More Information#

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