OP RP-Initiated Logout and user's presence

[Andrii Deinega]

https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout states clearly that

An RP requests that the OP log out the End-User by redirecting the End-User's User Agent to the OP's Logout Endpoint

it would be a significant improvement from a security perspective if this spec, or a new specification (extension), allowed an RP to request the OP to log out a user without his presence (when it’s permitted by the OP polices). There are lots of cases where it’s impossible to redirect a user say when the user closes his laptop and goes home. For this sort of cases, it’s highly desirable to clearly communicate via a reliable backchannel to the OP: “hi, you know, I’ve logged this user off so that a new auth request from him needs to be authenticated, and also please, invalidate his access token issued before to me“.

There are ways to handle this now:

1. use the token revocation endpoint (so an RP can invalidate an AT)
2. force a user to be authenticated for all authentication requests from an RP (with the help of the prompt parameter set to login)
3. rely on Shared Signals and Events Framework (SSE) & CAEP events

However, these methods have their downsides and don’t provide a simple, comprehensive solution.

Lastly, I discussed this use case a bit with Mike Jones at a recent IIW, and he suggested at least to fill an issue for tracking purposes.

[Nat Sakimura]

The call on June 17 asked why the token revocation endpoint did not do the job. If you could explain that in more detail, it would be much appreciated.

[Tom Jones]

I know that on a chromebook the easiest way to pause something like a youtube video is to shut the laptop and reopen it to continue. I don’t like the idea of one RP shutting down any session by going to the OP. They can cancel any access that they want to. I dislike the idea of the RP and OP colliding in any way.

[Andrii Deinega]

@Nat Sakimura , while the token revocation endpoint invalidates an access token, it doesn’t invalidate a user session at an OP (at least, the session associated with my RP). Moreover, in case of OpenID Core spec we don’t always actually get an access token (response_type=id_token). There is also another thing, the token revocation endpoint, simply isn’t always exposed / available.

Occasionally, I need to talk with the security teams that have this requirement; a user session needs to be invalidated due to inactivity, as well as in a few other “urgent“ use cases. In case of OpenID Connect, when a session at my RP gets invalidated in ether way, I would like to “notify” an OP about that regardless of user’s presence. I also would like to do it in a very interoperable(1), simple (2), and reliable way. At the same time, it’s still very much desirable to not set the prompt parameter to login, so the users can leverage an SSO experience if it happens they have an active session at their OP in normal cases.

I agree that one RP shouldn’t be able to revoke the “global” session at an OP, that would cause all kinds of trouble for other RPs. However, I do believe there is still a need to have a way for an RP to reliably notify OPs, “I’ve logged off the user.“

I should have joined today’s call to discuss this in detail.

[Tom Jones]

Why should an OP care if the RP has signed out the user? It none of the OP’s business!!

[Andrii Deinega]

Let's imagine, for a second, that https://youtube.com/ does not like something that your browser is doing (internally, or internally) while you watch a video on it, and it's logs you out from it, it also notifies https://accounts.google.com/ via some proprietary mechanism.

It works for Google because it controls two resources https://youtube.com/ as an RP, and accordingly https://accounts.google.com/ as an IDP and they can implement and rely on any proprietary mechanisms they want.

It quickly stops to work that that well when we control RPs but IDPs are not under our control, in addition to that, we deal with IDPs (OPs) built and came from tons of different companies & vendors.

I did not have a goal to go deep into discussions whether "Why should an OP care if the RP has signed out the user? It none of the OP’s business!!", maybe it, maybe it isn't but the users go to RPs (they want to watch videos, etc.). So, it could be beneficial for users and us, us as the community, for an RP to be able to say to an OP “I’ve logged off the user.“ in a simple, reliable and in interoperable way with, or without user’s presence. The next steps for an OP will be controlled by its policies / posture, etc.

[Tom Jones]

sounds like a really great denial of service attack to me. If this passes i would insist that every permission request inform the user that their behavior can be reported to the OP. AND that the consent request be a MUST, not optional as it is today. The users are already given short shrift by OIDC now - and you want to make it worse?

[Aaron Parecki]

On today’s call we clarified the intent of the request:

The RP would like to signal that the OP should not issue new tokens to the same RP without reauthenticating the user, without affecting any OP state associated with other RPs. (Removing the term “session” from the request cleared this up for me.)

I suggested to do some additional research on whether prompt=login and prompt=none might be able to solve the problem, and to document what might be missing from using these parameters instead of a new mechanism.