OpenID Connect Back-Channel Logout


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:

OpenID Connect Provider SHOULD also register the OpenID.Discovery related metadata value:

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.

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:

Relying Party SHOULD also register this related metadata value:

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.

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

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: