Front Channel Communication:
This specification defines a logout mechanism that uses front-channel communication via the User Agent between the OP and RPs being logged out that does not need an OpenID Provider iframe on Relying Party pages. Other protocols have used HTTP GETs to RP URLs that clear login state to achieve this
Relying Party Logout Functionality
RPs supporting HTTP-based logout 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 Redirection URI value.
The OP renders '
The OP MAY add these query parameters when rendering the logout URI, and if either is included, both MUST be:
iss
Issuer Identifier for the OP issuing the front-channel logout request.
sid
Identifier for the Session.
The RP'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
Example Front-Channel Logout URL Usage
In this non-normative example, the RP has registered the frontchannel_logout_uri value https://samplecreative.com/frontchannel_logout" with the OP. In the simple case, in which frontchannel_logout_session_required is false, the OP causes the front-channel logout to occur by rendering this URL in an iframe:
https://samplecreative.com /frontchannel_logout
In a second example, in which front_channel_logout_session_required is true, Issuer and Session ID values are also sent. This example uses an Issuer value of https://samplecreative.com and a Session ID value of 09a5019c-47e1-4977-8f42-65a12843ea02. In this case, the OP causes the front-channel logout to occur by rendering this URL in an iframe (with line breaks for display purposes only):
https://samplecreative.com /frontchannel_logout
?iss=https://samplecreate.com
&sid=09a5019c-47e1-4977-8f42-65a12843ea02
Back end channel
OpenID Connect Backchannel logout is a mechanism by which Relying Party (RP) applications are logged out with logout requests communicated directly between RPs and OpenID Providers (OP) bypassing the User Agent.
This logout mechanism is much less fragile than the other methods using front channel communication as it does not depend on the End-User’s browser activity. This may seem like the best option for OIDC logout — however, it is not the case for every scenario as it imposes new requirements on the system.
An Overview
When an RP or the OP triggers a logout action, the OP finds all the RPs who share the same user’s session at the OP.
The OP then generates a special JWT token called the Logout Token containing relevant claims for each RP and sends logout requests with the Logout Tokens to the logout endpoints of every RP.
Upon receiving a Logout Token, the RP much validate the token and invalidate the session of the particular user.
Logout Token
The Logout Token is a JWT much like the ID Token in OpenID Connect, and is also a type of Security Event Token. It contains Claims specific to the logout action that are required by RP applications to validate and verify the logout request and trigger the logout process for a particular user.
The following Claims are used within the Logout Token:
iss — Issuer Identifier. This is a case sensitive URL of the entity that generated the token (OP). This is a required field.
sub — Subject Identifier. It is a unique identifier assigned by the Issuer to the Client. This field is optional.
aud — Audience. The list of Clients to which the Logout Token is intended for. This is a required field.
iat — Issued At Time. Time at which the token was issued. This field is required as well.
jti — JWT ID. Unique identifier for the token. This is used to prevent Logout Token replays. This field is required.
events — JSON object containing the member name “http://schemas. openid.net/event/backchannel-logout”. The value of the member should be an empty JSON object. This is to declare that this JWT is a Logout Token. This field is required.
sid — Session ID. Identifier for a session of the User Agent at the RP. This field is optional.
Although the sid and sub Claims are considered optional, a Logout Token must contain either one of the Claims and may contain both. If the sid Claim is absent, the RP should log out all sessions of the End-User identified by the iss and sub Claims. The nonce Claims should NOT be included in a Logout Token for security reasons. Logout Tokens MUST be digitally signed and MAY also be encrypted. The following is an example of a Logout Token,
{
“iss”: “https://samplecreative.com",
“sub”: “248289761001”,
“aud”: “s6BhdRkqt3”,
“iat”: 1471566154,
“jti”: “bWJq”,
“sid”: “08a5019c-17e1–4977–8f42–65a12843ea02”,
“events”: {
“http://schemas.openid.net/event/backchannel-logout": {}
}
}
How it works
The Backchannel Logout process is initiated when the OP sends an HTTP(S) POST logout request to the backchannel logout URI of the RP registered at the OP. Such a logout request would look like this:
POST /backchannel_logout HTTP/1.1
Host: samplecreative.com
Content-Type: application/x-www-form-urlencoded
logout_token=eyJhbGci ... .eyJkc3M5f ... .T3BlbklE ...
Upon receiving a logout request, the RP should carry out necessary validation steps to ensure that the logout action is legit. The validation steps are described here. If anything goes wrong with the validation steps, the logout request should be rejected, and the RP must return an HTTP 400 to the OP.
Once validation is complete and successful, the RP must locate the sessions identified by the iss and sub Claims in the Logout Token and clear any state associated with those sessions. Refresh Tokens without the offline_access property should be revoked as well. The mechanisms by which the RP carries out these tasks are implementation specific and are not strictly defined by the spec.
In the event an RP is also an OP serving downstream logged-in sessions, upon receiving a logout request, it should generate logout requests to all the logged-in downstream RPs as well.
Once logout is succeeded, the RP responds back to the OP with an HTTP 200 OK and the Backchannel logout process is finally finished.
OpenID Connect Provide the following provider endpoints