OpenID Connect - how to handle single logout

Question

I'm investigating the use of OpenID connect as the SSO protocol for our enterprise applications (that are consumer facing). In general most aspects of it align with our needs, except for its ability to handle single logout and am hoping for some guidance on this.

I've had a chance to review the latest OIDC session management spec, as well as several stack overflow questions that touched upon similar themes:

• OpenID Connect will eventually replace saml...
• single sign off using oauth2

As the person from ping mentioned, single logout is handled differently from SAML2 in that it is more user centric. That's all good but it still doesn't feel like fitting the needs of actual single logout. Specifically, the user-centric handling (through somewhat kludgy iframe communication) only works for the current browser view, but wouldn't apply to an RP that isn't currently being viewed.
For example, the user logs into RPs A, B, and C using a specific OP. Single logout would only trigger logout for those RPs that a browser is viewing; that would leave those other sessions lingering, which can be a security issue. (please correct if I've mis-analyzed this though).

I've seen some solutions that work outside of the protocol (e.g. parent domain cookie, or possibly (??) the same session store) but those unfortunately would not fit my needs.

I'm trying to see if I may have missed something about the OIDC spec which suggests a single logout protocol covering use cases similar to SAML2's own single logout? (maybe some direct OP->RP communication? or even a client-side "iterate-through-RP" logout?). Or am I really left on my own to develop a proprietary solution for it?

BTW, would also be curious as to whether this has been discussed in the OIDC committee (am sure it has), and whether it is on the roadmap to be addressed.

Thanks in advance for the help!

Answer 1

What kind of solution do you expect?

SLO will work fine if you use OIDC for protection of your resources (you will check access_token on access to resources anyway, which will be revoked) but not in case when OIDC used as an Identity Provider.

OIDC has no push-SLO. You cannot implement a reliable SLO within the OP by the means of OIDC.

At the moment each RP should take care of SLO, which is specified in OIDC Session Management spec mentioned by you. If RPs are out of your control, you have no means to enforce it.

Answer 2

You mentioned 'some direct OP->RP communication' ; that's exactly what the Back-Channel Logout mechanism does.

Each client registered at the OP includes the backchannel_logout_uri; when the user logs out of the OP, the OP uses an http POST to this URI at every signed-in RP to tell them to log the user out.

Because this goes to the client system's back-end, it will work even if the user doesn't have a browser session with the client system's front-end active.