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 Partys 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 must implement an application-specific method of terminating Relying Party sessions with the OpenID Connect Provider upon receiving OpenID Connect Back-Channel Logout 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 OpenID Connect Back-Channel Logout 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.
OpenID Connect Provider SHOULD also register the OpenID.Discovery related metadata value:
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:
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 Partys as part of its logout actions.
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
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.