!!! Overview
[{$pagename}] specification defines a [logout] mechanism that uses [Front-channel communication] to communicate [logout] requests from the [OpenID Connect Provider] to [Relying Parties|Relying Party] 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. [{$pagename}] 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|Relying Party] 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:
%%prettify 
{{{
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:
[{ReferringPagesPlugin before='*' after='\n' }]