OpenID Connect Back-Channel logout 1.0

OpenID Connect 1.0 can use front-channel communication or back-channel communication for logout mechanism.

• Front-Channel mechanism : Communication of logout request from OpenID provider (OP) to Relying Party (RP) via User Agent (web browser)
• Back-Channel mechanism : Direct communication between OpenID Provider (OP) and Relying Party (RP)

Overall view of back-channel logout mechanism.

• For an instance, an end-user login to a third party app (Relying party) using Facebook( OpenID provider). So when the end-user logout from Facebook, Facebook should send a logout request to the third party app through a logout token.
• When the third party receives the logout request from Facebook, it will validate the logout token and will terminate the session of the end-user.
• So now the user logged out from the third party app by logging out from Facebook.

view of OIDC back-channel logout

Pros of back-channel mechanism

• Back-channel communication can be more reliable than communication through the User Agent. Because in front channel, RP’s browser session must be active for the communication to be succeed.

Cons of back-channel mechanism

• In front channel mechanism, session state is maintained over OP and RP using cookies and HTML5 local storage. But those are not available in back-channel mechanism. So the state must be explicitly communicated between OP and RP.
• In front-channel logout, logout happens simply by clearing cookies and HTML5 local storage state. But in back-channel mechanism, RPs must implement an application-specific method of terminating RP sessions with the OP upon receiving back-channel logout requests.
• The RP’s back-channel logout URI must be reachable from all the OPs used. This means, for instance, that the RP cannot be behind a firewall or NAT when used with public OPs.

Logout Token

It is a JSON Web Token (JWT) that contains Claims about the logout action being requested (similar to an ID Token).

In OpenID Connect 1.0, ID token is used to send claims about the end-user. Similar to that, In Back-channel logout, a logout token is used to when OpenID Provider (OP) indicates the RP to logout and it contains logout action.

{
   "iss": "https://server.example.com",
   "sub": "248289761001",
   "aud": "s6BhdRkqt3",
   "iat": 1471566154,
   "jti": "bWJq",
   "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
   "events": {
     "http://schemas.openid.net/event/backchannel-logout": {}
     }
  }

This is a logout token. Here,

• iss : Issuer Identifier (REQUIRED)
• sub : Subject Identifier (OPTIONAL - This MUST contain the client_id of the OAuth Client)
• iat : Issued at time (REQUIRED - Time at which the JWT was issued)
• jti : JWT ID (REQUIRED - Unique identifier for the ID token)
• events : This consists a JSON object consists http://schemas.openid.net/event/backchannel-logout {} and it should be empty. This declares that this token is a logout token (REQUIRED).
• sid : Session ID (OPTIONAL - String identifier for a Session. This represents a Session of a User Agent or device for a logged-in End-User at an RP. Different sid values are used to identify distinct sessions at an OP. The sid value need only be unique in the context of a particular issuer. Its contents are opaque to the RP. Its syntax is the same as an OAuth 2.0 Client Identifier.)

What should a RP provide to support back-channel logout?

Back-channel logout URI: URL that will cause the RP to log itself out when sent a Logout Token by the OP.

• When Relying Parties register them in the OpenID Provider, it should register a back-channel logout URI to indicate that they support back-channel-based logout.

How OIDC Back-channel logout function?

• The OP uses an HTTP POST to the registered back-channel logout URI to trigger the logout actions by the RP.
• The body of the POST method will look like as follows. This POST method consists logout token.

POST /backchannel_logout HTTP/1.1
  Host: rp.example.org
  Content-Type: application/x-www-form-urlencoded

  logout_token=eyJhbGci ... .eyJpc3Mi ... .T3BlbklE ...

1. Once the RP receives logout token from OP, it will validate the token. (see OpenID Connect Back-Channel Logout 1.0 — draft 04 for token validation)
2. If any of the validation steps fails, it will reject the logout token and return an HTTP 400 Bad Request error. Otherwise logout process will start.
3. After receiving a valid Logout Token from the OpenID Provider, the RP locates the session identified by the iss and sub Claims and/or the sid claim.
4. The RP then clears any state associated with the identified session(s) (If the identified End-User is already logged out at the RP when the logout request is received, the logout is considered to have succeeded).
5. If the logout succeeded, the RP MUST respond with HTTP 200 OK. If the logout request was invalid, the RP MUST respond with HTTP 400 Bad Request. If the logout failed, the RP MUST respond with 501 Not Implemented. If the local logout succeeded but some downstream logouts have failed, the RP MUST respond with HTTP 504 Gateway Timeout.

Security concerns

• Similar to ID token, logout-token should also be signed by OP in order to prevent from denial of service (an interruption in an authorized user’s access to the third party app when someone captured the logout token). By signing the logout token by OP, RP can ensure that this logout token is from a legitimate party.
• 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 re-playable.
• The kinds of Relying Parties that can be logged out by different implementations will vary. For an example, a relying party can use a mobile app and a web app. So IT should be clear, for instance, whether they are capable of logging out native applications or only Web RPs.

References: OpenID Connect back-channel logout spec draft-04

Learn, code !