18

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!

Vince Bowdren
  • 8,326
  • 3
  • 31
  • 56
Peter
  • 181
  • 1
  • 4

4 Answers4

3

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.

Vilmantas Baranauskas
  • 6,596
  • 3
  • 38
  • 50
3

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.

Vince Bowdren
  • 8,326
  • 3
  • 31
  • 56
1

There is no official solution for this, and as Vilmantas has correctly pointed out in his answer:

If RPs are out of your control, you have no means to enforce it.

Anyway, there still is an option, although this may contradict the use of OpenID Connect, but anyway, here we go:

Use a token revocation list.

When the user signs out, put the token on a revocation list at the identity provider. Then you need a mechanism to push (or regularly pull) this revocation list to all the relying partys' backends. Then, when the user tries to access a relying party (and they still have their token), although the token is basically still valid, the relying party can reject it because it had been revoked meanwhile.

Of course this means that you need some kind of ideally-real-time-update for the revocation lists, and this might render the entire idea of OpenID Connect useless. But it's an option…

Golo Roden
  • 140,679
  • 96
  • 298
  • 425
0

If your OAuth server issues refresh tokens, and it implements RFC 7009 then you can use that endpoint to revoke the refresh token, and prevent it from being used to issue any new access tokens.

We use this successfully in a scenario with a long (12 hour) refresh token and short (5 minutes access token). And for good measure the OAuth server also marks sessions as idle (essentially a revoke) when no new access token has been requested within a certain period (30 minutes).

Community
  • 1
  • 1
Bart Verkoeijen
  • 16,545
  • 7
  • 52
  • 56
  • out of interest, doesn't your "good measure" of revoking idle sessions after 30 minutes negate the point of having refresh tokens with a life of 12 hours - because after 30 minutes they would be useless anyway? Or have I just got the wrong end of it ? asking for a friend... thanks – Andy Lorenz Mar 15 '23 at 17:52
  • @AndyLorenz Requesting an access token would push the 30min rolling window. So if you sleep the computer that's running the app, and it doesn't refresh within 30min, the session ends. Otherwise, if you're an active user it keeps rolling the 30min window forward for a maximum of 12 hours. – Bart Verkoeijen Mar 26 '23 at 07:54