Session cleanup via back-channel
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
- The upstream IdP notifies the OP of a session termination via back-channel
- 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
Comments (8)
-
-
- changed milestone to Final
-
assigned issue to
John volunteered to write up a concrete proposal.
-
Account Deleted - attached session-end-callbacks-20131031.html
I've attached the spec for our implementation of back-channel session termination notification.
-
Account Deleted 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 )
-
- changed status to open
-
- changed milestone to Implementer's Draft
- changed component to New
-
- changed status to resolved
This issue has been resolved by the publication of http://openid.net/specs/openid-connect-backchannel-1_0.html .
-
Issue
#983was marked as a duplicate of this issue. - Log in to comment
Good starting point.
In addition, I would do the following: