Session cleanup via back-channel

[Pedro Felix]

I've a scenario where a OIDC OP is acting as a bridge between upstream IdPs using non-OIDC protocols (e.g Shibboleth) and downstream RPs using OIDC. In this scenario I have the following requirements

1. The upstream IdP notifies the OP of a session termination via back-channel
2. The OP needs to propagate this cleanup notification to the downstream RPs, also via back-channel (a back-channel to front-channel transition is not possible)

OIDC should define an optional mechanism to perform this type of IdP-initiated cleanup via back-channel. From, the RP viewpoint, the requirements are:

• correctly identify the originator of the request - the OP
• correctly identify the destination of the request - itself
• correctly identify the session's subject

An option would be for the OP to make a request to a "cleanup endpoint" using a bearer JWT with:

• "iss" set to the OP issuer claim
• "aud" set to the RP's client_id
• "sub" set to the user's unique claim
• "nbf" and "exp" defining a rather short interval, to avoid replays

[Nat Sakimura]

Good starting point.

In addition, I would do the following:

• Define and have the client register the session termination notification endpoint to the OP;
• Sign the JWT, either by MAC or RSA or ECDSA so that the originater (OP) can be authenticated. Perhaps MAC is good enough.

[Michael Jones]

John volunteered to write up a concrete proposal.

[Former user]

I've attached the spec for our implementation of back-channel session termination notification.

[Former user]

Note that we've chosen, perhaps temporarily, not to implement back-channel session signout notification.

Related to this, we found the spec submitted in the previous comment to be unworkable given that an individual RP may obtain multiple ID tokens over the course of a single OP session. This is especially true when the check session frame mechanism is being used (the RP typically sends an authentication request to the OP each time the OP browser state changes, and likely gets issued a fresh ID token on each occasion).

One way to fix the spec would be to introduce some sort of OP session id claim into the ID token. All ID tokens issued to a RP for the same OP session would carry the same OP session id. When the OP reports a session sign-out notification, the OP would send a fresh ID token carrying that OP session id to each client with a registered sign_out_callback_uri known to have ever obtained an ID token for that OP session. The receiving RP could validate the ID token (i.e., check OP signature, audience, exp, etc.), extract the OP session id, and then go about killing off any of its sessions based on that session id. (The revised spec would involve defining a claim name of some ilk: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19#section-4.2 )

[Michael Jones]

This issue has been resolved by the publication of http://openid.net/specs/openid-connect-backchannel-1_0.html .

[Michael Jones]

Issue #983 was marked as a duplicate of this issue.