Add logout_hint parameter to RP-Initiated Logout request

Issue #1182 resolved
Michael Jones created an issue

The AAD team at Microsoft wants there to be a logout_hint parameter paralleling the login_hint parameter for authentication. The language would closely parallel the login_hint description proposed by @gffletch near the end of issue #1046 . This is also closely related to @Filip Skokan 's suggestion of a client_id parameter, although more general. (@panva - maybe you can add a link to your issue as a comment.)

They have situations where they don’t have the ID Token to use for the id_token_hint, but still want to specify the entity to be logged out - just like login_hint can be used to specify the entity to be logged in.

Comments (17)

  1. Filip Skokan

    I am not opposed to the suggestion but would like to point out that it's based on a premise that was previously marked as erroneous and dismissed another suggestion that solved real functional and processing problems.

    They have situations where they don’t have the ID Token to use for the id_token_hint, but still want to specify the entity to be logged out

    During at least 3 WG calls (spanning half a year) when we discussed the mentioned #1032 issue it was stated several times that not keeping the ID Token for the purposes of using it as id_token_hint is erroneous client behaviour.

    The sentiment from a number of attendees on yesterday's (13-Aug-20) WG call was not entirely backing up that statement, in general, cases when the AS doesn't know the calling client, specifically

    • there are RP deployments that establish their own session mechanism based on the ID Token returned from an Authentication Request but do not have the capability (or capacity) to store the ID Token value for later use. Storing the full ID Token value just so that an RP can perform a logout without losing control of the User-Agent to the OP is an overkill given how large ID Tokens are known to get in some cases, not being able to act on a registered post_logout_redirect_uri just because of this is a big deficiency of the specification.
    • ID Token may be symmetrically encrypted in which case the OP needs a hint to load up the client secret that is used to derive the symmetric secret used for encryption/decryption.

    I have prepared a proposal that deals with the Security Consideration around Denial of Service in Section 6 (Security Consideration) by clearly stating when an end-user prompt is mandatory. This incorporates this logout_hint as well my client_id suggestion.

    Summary of the changes

    • Clarified statements about the end-user prompt at the logout endpoint. OP SHOULD prompt the End-User to confirm logout but MUST do so if id_token_hint was not provided or if its claims no longer suggest it relates to the current OP session and/or currently logged in end-user.
    • client_id (OPTIONAL) parameter was added to aid in processing the logout request with a post_logout_redirect_uri. When both client_id and id_token_hint are provided the OP must verify the client_id is the one the ID Token was issued to.
    • logout_hint (OPTIONAL) parameter was added to aid the OP in rendering a "preselected" session to confirm logout with. It's defined, as suggested, similar to #1046 login_hint in a way that its meaning is left up to the OP's discretion.
    • Other changes spanning from the above just tie up loose ends

    Find the proposal here.

  2. Michael Jones reporter

    Having an optionalsid parameter on the RP-Initiated logout request may arguably be more useful than client_id, as it tells you which of the potentially multiple users logged in at the RP is to be logged out. (And I’ll note that you can determine the client_id from the sid).

    If we do this, I’d suggest language something like the following, which is derived from similar language in the Front-Channel Logout spec:

    sid (session ID) parameter MAY be included by the RP to enable the OP to determine which of the potentially multiple sessions is to be logged out.

    That said, support for sid is optional (see the frontchannel_logout_session_supported and backchannel_logout_session_supported metadata values). OPs not supporting multiple logins at the same RP are likely not to support it.

    I know that @gffletch spoke up for the possibility of a sid parameter on the latest call.

    If we have logout_hint and sid parameters, do we also need client_id?

    (Sadly if we could count on having the id_token_hint, we wouldn’t need to be having any of this discussion, but apparently that’s not always realistic in the marketplace of deployed OPs.)

  3. Filip Skokan

    If we have logout_hint and sid parameters, do we also need client_id?

    Neither sid nor logout_hint help make post_logout_redirect_uri actionable if the sessions present at the OP have diverged, that is what my proposal about the end-user prompt, client_id, and id_token_hint is also covering.

    In a way i see logout_hint more versatile than sid in that it is OP specific, and still believe that if we go about entertaining the notion that it’s okay for RPs not to retain the ID Token to be able to send an id_token_hint (by adding these backfilling hints) we should also add a client_id to make post_logout_redirect_uri reliably actionable.

    (Sadly if we could count on having the id_token_hint, we wouldn’t need to be having any of this discussion, but apparently that’s not always realistic in the marketplace of deployed OPs.)

    You meant RPs, right?

  4. Filip Skokan

    From Spec Call Notes 27-Aug-20

    Post-logout redirection should only happen to RPs that have recently been logged in and to registered post_logout_redirect_uri values

    Where do we state such (in bold) requirement or sentiment? If we’d be adding hints that are carried by an id token that a client didn’t keep we should accommodate all use cases, that includes making sure post logout redirection is always actionable. In my proposal there’s an end user prompt normatively required anyway so what’s the harm?

  5. Michael Jones reporter

    Per my action item from the 27-Aug-20 call, I’m recording here that there appeared to be support for adding sid and logout_hint parameters as selection hints, which people felt were safe, given the user interaction. Adding client_id seemed duplicative, however we should continue discussing it, per @Filip Skokan 's points.

    Responding to @Filip Skokan ‘s question above, we haven’t yet said in the spec that

    Post-logout redirection should only happen to RPs that have recently been logged in and to registered post_logout_redirect_uri values

    This was a possible guideline discussed on the call. We should discuss whether people agree with it. It was mentioned as a heuristic to work around unfortunate situation that we apparently can’t rely upon RPs giving us an id_token_hint.

    Hopefully we can continue discussing this and related issues on today’s call.

  6. Filip Skokan

    Post-logout redirection should only happen to RPs that have recently been logged in and to registered post_logout_redirect_uri values

    While i’m not opposed to this it’s not really a workaround unless normative and it doesn’t even deal with id_token_hint not being kept by a client at all.

    Circling back, if we’re recognizing unkept id_token as a possible (although as stated, unfortunate) situation, we should also make it possible for clients to use post_logout_redirect_uri in such situation. My proposal makes that situation safe by requiring an end-user prompt, a condition which in the current state of the specification is also very poorly specified btw. So, I believe that, making it required in those unfortunate scenarios gets around previously mentioned DoS and “open” (not really, it’s still based on a pre-registered list of uris) redirection issues.

    Even without the required prompt a request to the logout endpoint with a client_id and a registered post_logout_redirect_uri is not much different “redirect-wise” from a request to the authorization endpoint with client_id, prompt=none, response_type=none and a registered redirect_uri.

    Note: I am not able to join the pacific call, i will be joining next week in the european one.

  7. Michael Jones reporter

    Per discussion on the 10-Sep-20 call, we will no longer require an error to occur when post_logout_uri is specified provided that a “sid” value is provided. If the “sid” isn’t known by the OP at that point the OP must prompt the end-user before performing the post-logout redirect. We will add “logout_hint” and “sid” parameters. A “client_id” parameter will not be added because it’s duplicative of “sid”.

  8. Filip Skokan

    @Michael Jones

    Per discussion on the 10-Sep-20 call

    A “client_id” parameter will not be added because it’s duplicative of “sid”.

    🔼 the group has not come to such conclusion on the call Mike. The discussion has exhausted the remaining call time and @Nat Sakimura suggested we continue it here.

    In a responsive to this preemptive resolution - “client_id” is not duplicative of “sid” in all scenarios, we’ve discussed that on the call and as such it is not helping to ensure the OP is always capable of checking the post_logout_redirect_uri against the correct post_logout_redirect_uris whitelist. As discussed on the call the added “prompt” doesn’t help that particular problem either.

    “client_id” in combination with “post_logout_redirect_uri” OTOH is a sure way to ensure a post logout is performed, in all scenarios, no exceptions. Albeit with a prompt included as per my suggested text above. These are two static parameters any developer / SDK can send to ensure 100% the result they wish to have at the end of the OP logout journey.

    Prompts solve the redirect concerns, yes. They don’t solve implementer’s concerns when it comes to processing other parameters. It was also suggested to keep historic “sid” parameters just for the sake of looking up the client_id, that is not a particularly good suggestion, it’s an implementer’s nightmare, the same is having “sid” a structured value that’s hinting at a client.

    Hints solve the “select a session to drop prompt” problem, they should not be used to imply which client entity to load so that other parameters can be made actionable.

    I believe @gffletch on the call as well as above @Brian Campbell support the addition of “client_id”, the rest on the calls have not contributed to the discussion. The sentiment against it remaining is that it is “yet another parameter” and we want to keep the surface minimal. I disagree with that as a reason not to introduce a parameter that helps to absolutely remove any complexity when it comes to post logout redirection - both OP processing-wise, and client-developer-side - there’s nothing to untangle when it comes to the combinatorics of parameters anymore when these two are present - as a developer i KNOW i will get the redirect i require all the time and then, when i’m not happy with the OP prompt content rendered i may add additional hint parameters to aid the OP prompt UX. That’s an API I as a developer expect - a set of static value parameters that help me achieve my JTBD - opposed to that the situation as we have it today where I have to keep my fingers crossed when sending an rp-initiated logout request hoping that the implementation supports the different hints (that i need to keep track of, but what if I don’t have them and just want to ensure no session is present on the OP) and can process my redirect.

    I would like to continue the discussion here on the tracker and/or on the next atlantic call (24-Sep-20) where I can participate.

    Pinging @John Bradley as his voice was also present in the discussion on the call.

  9. Brian Campbell

    Meeting notes support that consensus was not reached on the call:

    6.1.   1182 Add logout_hint parameter to RP-Initiated Logout request (Mike)

    The issue was discussed over 30 minutes but has not come to a consensus. The main topic was whether to include client_id in the request parameter so that the error can be returned to RP so that RP can take appropriate action.

    Mike Jones opposed the idea that adding a parameter will increase the number of combinations of possible parameters and will likely get less support from OPs but Filip and George were not convinced.

    Filip also proposed a text in the issue that will be backwards compatible and yet allows the response to be returned to the RP.

    John proposed a solution that requires the prompting and Filip told that it does not help him to load up the client and verify.

    As it was approaching the end of the call, Nat intervened and asked to take the discussion either offline and report back to the WG or continue next week.

  10. gffletch

    Personally… I still don’t understand why keeping the id_token is such a problem:) If the RP is a web site and doesn’t store state, it could encrypt the id_token and stuff it in a cookie and use the browser as its “session storage”. For mobile apps, keeping the id_token around doesn’t cost much.

    That said, if we can’t expect people to save the id_token to use with logout, then for the case of validating the post_logout_redirect_uri I think it makes good sense for the client to specify its client_id. It is the clear identifier to the AS for validating the redirect URI and it solves a separate problem from that of identifying which session to logout.

    I think we should look at these issues as separate.

    1. How to validate the post_logout_redirect_uri
    2. How to identify which session (if there are multiple) that the client wants logged out

    For the first we need ‘client_id’ and for the second we need ‘logout_hint’ or ‘sid’. We probably don’t need both.

  11. Vittorio Bertocci

    Sorry for chiming in late on this, gmail ate the last 2 months of list emails.
    Catching up on the discussion, I wanted to say I support the principle of using information already available and understood by the clients, and that AS must already handle, as much as viable - client_id certainly falls into that category, hence it would seem odd to deny developers the ability to use it in this context.
    On clients keeping the id_token value around, let me add some color. The fact that it’s (relatively) easy doesn't mean that developers and SDK providers do that, as we well know- in fact, some of the most adopted SDKs for OIDC signin on ASP.NET required the dev to explicitly opt in to keep the id_token value in the session, and even the devs knowing about the option usually don't go for it for fears of exceeding the allowance for the domain (on safari exceeding 4K means clipping stuff, and it’s not hard to get there considering id_tokens carrying profiles and custom claims, saved both as id_token and deserialized form, hence taking ~twice the size in the same cookie).
    The other consideration is that whatever persistence layer is used for storing the id_token has at least some risk of being wiped, corrupted or otherwise invalidated during the application’s lifetime (eg imagine browsers deleting cookies, just because). Any logic relying on data stored in there would need to make provisions for the possibility of the id_token bits becoming somehow irretrievable, whereas code based on static configuration values (such as the client_id) would be far more robust.

  12. Filip Skokan

    We have discussed, on the 14-Jan-21 call, that @Michael Jones will publish a new draft version with this proposal incorporated, that is, to add both logout_hint and client_id optional parameters.

  13. Michael Jones reporter

    We agreed on the 14-Jan-21 working group call to publish a new draft adding optional client_id and logout_hint parameters, making it clear that the session ID can be the logout_hint value.

  14. Log in to comment