!!! Overview
[{$pagename}] specification defines an [OpenID Connect Provider] initiated [Logout Mechanism] that uses direct [back-channel Communication] between the [OpenID Connect Provider] and [Relying Parties|Relying Party] being [logged out].

[Relying Party]-initiated [logout] functionality specified in Section 5 of [OpenID Connect Session Management] 1.0 [OpenID.Session] by reference. All the same [metadata] values and messages are used by the [Relying Party] to request that the [OpenID Connect Provider] logout [Relying Party]s and then possibly redirect back to the initiating [Relying Party] as are used in that specification. Therefore, they __are not repeated__ here.

An upside of [back-channel Communication] is that it can be more reliable than communication through the [user-agent], since in the front-channel, the [Relying Party]'s [browser] [session] must be active for the communication to succeed. (If the [Relying Party]'s [browser] tab was subsequently used to navigate to an unrelated page, the [Relying Party] [session] will be active unless the user uses the back button to return to it.) 

Both the [OpenID Connect Session Management] 1.0 [OpenID.Session] and [OpenID Connect Front-Channel Logout] 1.0 [OpenID.FrontChannel] specifications use [front-channel communication], which communicate logout requests from the [OpenID Connect Provider] to [Relying Party]'s via the [user-agent].

A downside of [back-channel Communication] is that the [session] state maintained between the [OpenID Connect Provider] and [Relying Party] over the front-channel, such as cookies and [HTML5] [local storage], are __not available__ when using [back-channel Communication]. As a result, all needed [state] must be explicitly communicated between the parties. Furthermore, [Relying Parties|Relying Party] must implement an application-specific method of terminating [Relying Party] sessions with the [OpenID Connect Provider] upon receiving [{$pagename}] requests; this can be more complicated than simply clearing [cookies] and [HTML5] [local storage] state, which is often all that has to happen to implement logout in response to front-channel [logout] requests.

Another significant limitation of [{$pagename}] is that the [Relying Party]'s back-channel [logout] [URI] must be reachable from all the OPs used. This means, for instance, that the [Relying Party] cannot be behind a [firewall] or [NAT] when used with public [OpenID Connect Providers].

!! 2.1 Indicating [OpenID Connect Provider] Support for Back-Channel Logout
If the [OpenID Connect Provider] supports [OpenID Connect Discovery] 1.0 [OpenID.Discovery], it uses this metadata value to advertise its support for [{$pagename}]:

* [backchannel_logout_supported] - [OPTIONAL] [Boolean] value specifying whether the OP supports back-channel logout, with true indicating support. If omitted, the default value is [false].

[OpenID Connect Provider] [SHOULD] also register the [OpenID.Discovery] related metadata value:
* [backchannel_logout_session_supported] [OPTIONAL] [Boolean] value specifying whether the [OpenID Connect Provider] can pass a [sid] ([session ID]) [Claim] in the [Logout Token] to identify the RP session with the [OpenID Connect Provider]. If supported, the [sid] [Claim] is also included in [id_token] issued by the [OpenID Connect Provider]. If omitted, the default value is [false].

!! 2.2.  Indicating [Relying Party] Support for [{$pagename}]
[Relying Parties|Relying Party] supporting [{$pagename}] register a back-channel logout [URI] with the [OpenID Connect Provider] as part of their [OAuth 2.0 Client Registration].

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

If the [Relying Party] supports [OpenID Connect Dynamic Client Registration] 1.0 [OpenID.Registration], it uses this metadata value to register the back-channel [logout] [URI]:
* [backchannel_logout_uri] [OPTIONAL] - [Relying Party] [URL] that will cause the [Relying Party] to log itself out when sent a [Logout Token] by the [OpenID Connect Provider].
[Relying Party] [SHOULD] also register this related metadata value:
* [backchannel_logout_session_required] [OPTIONAL]. [Boolean] value specifying whether the [Relying Party] requires that a [sid] ([session ID]) [Claim] be included in the [Logout Token] to identify the [Relying Party] [session] with the [OpenID Connect Provider] when the [backchannel_logout_uri] is used. If omitted, the default value is [false].

!! 2.3. Remembering Logged-In [Relying Parties|Relying Party]
[OpenID Connect Providers] supporting [{$pagename}] need to keep track of the set of [logged-in] [Relying Parties|Relying Party] so that they know what [Relying Parties|Relying Party] to contact at their [backchannel_logout_uri] to cause them to log out. Some [OpenID Connect Providers] track this state using a "visited sites" [cookie]. [OpenID Connect Providers] are encouraged to send [logout] requests to them in parallel.


!! 2.7. [{$pagename}] Logout Actions
After receiving a valid [Logout Token] from the [OpenID Connect Provider], the [Relying Party] locates the session(s) identified by the [iss] and [sub] Claims and/or the [sid] [Claim]. The [Relying Party] then clears any [state] associated with the identified [session](s). The mechanism by which the [Relying Party] achieves this is implementation specific. If the identified [End-User] is already logged out at the [Relying Party] when the logout request is received, the logout is considered to have succeeded.

In the case that the [Relying Party] is also an OP serving as an identity provider 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]/OP send logout requests to its downstream [Relying Party]s as part of its [logout] actions.

* [Refresh_tokens] issued __without__ the [offline_access] property to a session being logged out [SHOULD] be [revoked|Token Revocation]. 
* [Refresh_tokens] issued __with__ the [offline_access] property normally [SHOULD NOT] be [revoked|Token Revocation]. 
NOTE: An open issue for the specification is whether to define an additional optional parameter in the [Logout Token], probably as a value in the event-specific parameters JSON object, that explicitly signals that [offline_access] refresh tokens are also to be revoked.

!! 2.8.  [{$pagename}] Logout Response
If the logout succeeded, the [Relying Party] [MUST] respond with [HTTP 200] OK. If the logout request was invalid, the [Relying Party] [MUST] respond with [HTTP 400] Bad Request. If the logout failed, the [Relying Party] [MUST] respond with [HTTP 501] Not Implemented. If the local logout succeeded but some downstream logouts have failed, the [Relying Party] [MUST] respond with [HTTP 504] Gateway Timeout.

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
}}} /%


!! 4. [Security Considerations]
The signed [Logout Token] is required in the [logout] request to prevent [denial-of-Service] [attacks] by enabling the [Relying Party] to verify that the logout request is coming from a legitimate party.

The kinds of Relying Parties that can be logged out by different implementations will vary. Implementations should make it clear, for instance, whether they are capable of logging out native applications or only Web RPs.

OPs are encouraged to use short expiration times in [Logout Tokens], preferably at most two minutes in the future, to prevent captured [Logout Tokens] from being replayable.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]