Add logout_hint parameter to RP-Initiated Logout request
Issue #1182
resolved
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)
-
-
I concur with what @Filip Skokan said above.
-
reporter
Having an optional
sidparameter on the RP-Initiated logout request may arguably be more useful thanclient_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 theclient_idfrom thesid).If we do this, I’d suggest language something like the following, which is derived from similar language in the Front-Channel Logout spec:
A
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
sidis optional (see thefrontchannel_logout_session_supportedandbackchannel_logout_session_supportedmetadata 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
sidparameter on the latest call.If we have
logout_hintandsidparameters, do we also needclient_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.) -
If we have
logout_hintandsidparameters, do we also needclient_id?Neither
sidnorlogout_hinthelp makepost_logout_redirect_uriactionable if the sessions present at the OP have diverged, that is what my proposal about the end-user prompt,client_id, andid_token_hintis also covering.In a way i see
logout_hintmore versatile thansidin 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 anid_token_hint(by adding these backfilling hints) we should also add aclient_idto makepost_logout_redirect_urireliably 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?
-
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?
-
reporter
Per my action item from the 27-Aug-20 call, I’m recording here that there appeared to be support for adding
sidandlogout_hintparameters as selection hints, which people felt were safe, given the user interaction. Addingclient_idseemed 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.
-
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.
-
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”.
-
@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.
-
Meeting notes https://bitbucket.org/openid/connect/wiki/Connect_Meeting_Notes_2020-09-10_Atlantic 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.
-
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.
- How to validate the post_logout_redirect_uri
- 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.
-
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_idcertainly 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 theclient_id) would be far more robust. -
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_hintandclient_idoptional parameters. -
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.
-
- changed status to open
Discussed on Mar 15 Call. Still waiting for the updates to the draft.
-
reporter
-
reporter
- changed status to resolved
- Log in to comment
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.
During at least 3 WG calls (spanning half a year) when we discussed the mentioned
#1032The 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
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_hintas well myclient_idsuggestion.Summary of the changes
#1046login_hint in a way that its meaning is left up to the OP's discretion.Find the proposal here.