Overview#OpenID Connect Back-Channel Logout specification defines an OpenID Connect Provider initiated logout mechanism that uses direct back-channel Communication between the OpenID Connect Provider and Relying Parties 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 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.
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 OpenID Connect Back-Channel Logout:
- 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.
- 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 OpenID Connect Back-Channel Logout#Relying Parties supporting OpenID Connect Back-Channel Logout 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.
- 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.
- 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#OpenID Connect Providers supporting OpenID Connect Back-Channel Logout need to keep track of the set of logged-in Relying Parties so that they know what Relying Parties 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. OpenID Connect Back-Channel Logout 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 Partys as part of its logout actions.
Refresh_tokens issued without the offline_access property to a session being logged out SHOULD be revoked. Refresh_tokens issued with the offline_access property normally SHOULD NOT be revoked. 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. OpenID Connect Back-Channel Logout 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:
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.