Menu
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:
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!
955
Logout works by directing the user's browser to the end-session endpoint of the OpenID Connect provider, with the logout request parameters encoded in the URL query string. The identity of the user to logout is specified by their ID token (obtained at login), set in the id_token_hint parameter.
Front-Channel Logout is handled through the user agent. For each client that has a session for the user from the OpenID provider and that supports the front-channel logout mechanism an iframe is rendered. This means that logout requests of all clients are performed in parallel.
OpenID Connect Single Sign-On (SSO) OpenID Connect (OIDC) is a protocol to verify user identities and get user profile information. OIDC enables devices to verify identities based on authentication done by an authentication server.
Single Logout (SLO) is a feature that allows a user to terminate multiple authentication sessions by performing a single logout action. Auth0 supports SLO when you connect your application to a SAML Identity Provider (IdP) and supports limited SLO when you configure Auth0 as a SAML IdP.
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.
81
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.
41
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
