Unclear what to do if id_token_hint user does not match currently logged in user at OP

Issue #1184 resolved
Mitar created an issue

In our case we maintain user session at OP web origin (a cookie) which serves to authenticate the user once they arrive on OP web sites. We are implementing OpenID Connect RP-Initiated Logout so that RP can request logout from OP which in our case we intend to use to clear this cookie and logout the user from OP as well.

I would like to suggest that the spec is clearer what is indented/suggested behavior if RP requests logout for user A, but currently logged user into OP (cookie set on OP’s web origin) is for user B:

  • Should OP just say “user A is not logged in anymore, great, let’s redirect back” and do not do anything about user B’s cookie.
  • Should OP ask the user B if they want to be logged out and then redirect back.
  • Should OP logout user B, ask for user A to be logged in, and then log out user A and redirect back?
  • Should OP temporarily pretend that user A is logged in and ask them to confirm logging out and then redirect back?

So this can happen if human has multiple accounts on OP. And they logged in as user A into OP when RP was requesting the ID token. But then in meantime logged in in as user B into OP maybe for some other RP. And then first RP tries to logout, user A is not logged in into OP anymore.

The issue is that when human wants to log out from inside RP, there might be at least two options the human would prefer:

  • They are using a public computer and when clicking log out inside RP they in fact want all sessions to be clear, both on RP and OP and they do not care really what is the user currently logged into OP.
  • They are aware that OP has user B logged in, but they would just like to log out from the RP as user A, not the OP as well.

What would be some suggestion what to do here?

Comments (9)

  1. Michael Jones

    We say in the logout specs that logout is idempotent - so repeating a logout is actually a success. Furthermore, as Vittorio pointed out in the 12-Apr-21 call, if you show UI in that case, you’ll confuse the user and it will no longer be idempotent.

  2. Michael Jones
    • changed status to open

    Based on logout being idempotent, it's not clear that a spec change is needed. If you believe that one is, can you please describe the change you're looking for? Thanks.

  3. Mitar reporter

    I would just like to understand which of the four options above should happen. So logout for user A is idempotent, but what if user B is logged into the OP when logout for user A is requested. What is idempotent behavior in that case? Maybe this is something trivial, but I do not see what to deduce here.

  4. Michael Jones

    The OP is free to silently ignore any malformed requests or to show UI to the End-User. But remember that sending malformed requests can be a means of denial-of-service attacks, so silently dropping them is probably better than asking the End-User questions that likely only confuse him or her.

    If people want to propose clarification text of this nature for the RP-Initiated Logout spec, I’d be glad to add it. Otherwise, I propose that we close this issue with no further action.

  5. Mitar reporter

    so silently dropping them is probably better than asking the End-User questions that likely only confuse him or her.

    Hm, but this might be a security issue on a shared computer. User clicks logout attempting to logout, OP silently ignores it, user leaves the computer, another user comes and can use it as the first user.

  6. Michael Jones

    Actually, I probably spoke too quickly. The RP-Initiated-Logout request causes a redirect to the OP. So there’s not actually an option for it to be silently ignored, because the End-User’s user-agent is no longer at the RP and the OP will display something. If the request is somehow malformed, the OP isn’t allowed to silently act upon it but it is free to ask the End-User if he/she wants to log out. That’s probably the preferred behavior.

  7. Log in to comment