[Openid-specs-ab] OpenID Connect Logout using HTTP GET
mail at alfred-albrecht.net
mail at alfred-albrecht.net
Mon Mar 2 13:48:46 UTC 2015
Hi Mike,
thanks for your feedback. Regarding best practices, i would like show how we at Deutsche Telekom handle OpenId Connect logouts:
Technically we are using JSONP to enable cross domain communication between RPs and OP.
- The OP calls each RP's logout endpoint, that is in session, to trigger the Logout.
- Each RP has to implement a simple callback that returns a value, that is defined by convention (e.g. HTTP 200 with the callback parameter OK once the RP's session is terminated).
- The OP evaluates the results (e.g. time outs) and reacts e.g. by showing a warning to the user if some RP went wild.
---
Alfred
Mike Jones schrieb am 27.02.2015 16:59:
> Thanks for your comments, Alfred. I agree that "logout_supported" may be an
> overly general name. Would people prefer "logout_uri_supported" instead?
>
> As for the foibles of logout via image GETs, I realize that it's best effort
> and browser behavior dependent, but it does seem to be the commonly supported
> least-common-denominator functionality across different federation protocols.
> It's what many had been asking for. That being said, if there are best
> practices we can document to ensure that it works as well as possible, we
> should definitely do that.
>
> Best wishes,
> -- Mike
>
> -----Original Message-----
> From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] On
> Behalf Of mail at alfred-albrecht.net
> Sent: Monday, February 23, 2015 12:40 PM
> To: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] OpenID Connect Logout using HTTP GET
>
> Hi.
>
> I'm working with Torsten at Deutsche Telekom. I'm sorry if my answer is
> misplaced regarding the position in the thread but I was not sure how to reply
> specifically to Mike Jones first thread on this topic without having subscribed
> the mailing list before. Below is my feedback on the one pager of Mike:
>
> - If the OP implements the RP-Pixel on the logout page it is hard to react on
> failed logouts of RPs, without using Java Script.
> - It is not possible to configure a time-out for the response of the RPs. The
> time out depends on the environment (e.g. os, browser).
> - The user is not able to see the visual feedback of the logout until all RPs
> have responded or timed out. That could take a while.
> - The images will be received generally synchronously. Some browsers support,
> as far as I know, asynchronously downloads but only to a small number of
> images. This could be interesting from the performance point of view.
>
> - The suggested parameter logout_supported in the discovery document is for my
> understanding a bit misleading, because I would think that it means logout in
> general and not just the support of GET-based logout.
>
> ---
> Alfred
>
>> -------- Originalnachricht --------
>> Betreff: Re: [Openid-specs-ab] OpenID Connect Logout using HTTP GET
>> Datum: 17.02.2015 13:42
>> Von: Justin Richer <jricher at mit.edu>
>> An: Thomas Broyer <t.broyer at gmail.com>, Mike Jones
>> <Michael.Jones at microsoft.com>, "openid-specs-ab at lists.openid.net"
>> <openid-specs-ab at lists.openid.net>
>>
>>
>> In my mind, the RP should never be generating an ID token. For logout
>> (or other id_token_hint uses), the RP should pass along the ID token
>> that it received from its last login event, even if it's expired. It's
>> essentially a "session key", tying the two actions together. The IdP
>> can validate the token even if it's dead already (check issuer,
>> signatures,
>> etc) and make sense of it in context of the requested action.
>>
>> -- Justin
>>
>> On 2/17/2015 4:51 AM, Thomas Broyer wrote:
>>
>>> One issue with this scheme is that this is typically implemented as
>>> web page with <img> elements and a <meta refresh> to redirect to some
>>> other place after all images have loaded, but empty/blank in all
>>> other aspects. That means that an misbehaving RP could impair the UX
>>> of the whole "platform" (and more specifically the OP) if it doesn't
>>> respond in a timely manner. Because there's no way to indicate
>>> timeouts in HTML, the only way to workaround this is to add
>>> JavaScript (setTimer in DOMContentLoaded, to trigger redirection
>>> before onload if that ones takes too much time, possibly cancelled in
>>> onunload if onload comes fast enough –shouldn't technically be
>>> needed, but not all browsers behave the same IIRC); and/or to add a
>>> message with a link to be clicked "if logging out takes too much time".
>>>
>>> Otherwise OK with the proposal overall. My notes below:
>>>
>>> I don't quite understand why it talks about the end_session_endpoint
>>> and post_logout_redirect_uris; it should just defer to RP-Initiated
>>> Logout, saying it extends it (so it must indeed be supported by the
>>> OP).
>>>
>>> In “OP Logout Functionality”, “register this related metadata value”
>>> should probably be “advertize this related metadata value”.
>>>
>>> What claims should be included in the id_token? What does the "exp"
>>> claim would stand for? IIUC, the "exp" claim for the ID Token
>>> initially returned during authentication represents the
>>> authentication expiration [1], but the logout_uri is called after the
>>> authentication has been revoked or has expired here, so the "exp"
>>> claim cannot have that meaning in this specific case. Should the
>>> id_token here be generated specifically for this call, with a very
>>> short expiration? or should/could it be the same as the one last sent
>>> to the RP during authentication? How should the RP validate it?
>>> (because it's not “received via direct communication between the
>>> Client and the Token Endpoint”, I suppose the RP MUST validate the
>>> signature?)
>>>
>>> [1] This, to begin with, is really not clear at all; it's only said
>>> once “in passing” in
>>> <https://openid.net/specs/openid-connect-core-1_0.html#Authentication
>>> [2]> without even mentioning the "exp" claim explicitly (“The
>>> Authentication result is returned in an ID Token, as defined in
>>> Section 2. It has Claims expressing such information as the Issuer,
>>> the Subject Identifier, when the authentication expires, etc.”; and
>>> note that this section, and thus this sentence, is absent from
>>> openid-connect-basic-1_0 for instance.) The "exp" claim is always
>>> defined as the “expiration time on or after which the ID Token MUST
>>> NOT be accepted for processing”, which is reflected in the “ID Token
>>> Validation” section
>>>
>> <https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidati
>> on
>>> [3]>, but that one only applies to validating the id_token received
>>> during authentication, not how the OP should validate id_token_hint
>>> at the authorization endpoint or end_session_endpoint, or the
>>> id_token at the logout_uri here. FWIW, I had originally understood
>>> that as that the ID Token could have a validity timeframe of a few
>>> minutes only, and that's how I implemented it! And the examples using
>>> an ID Token with a validity timeframe of 1000 seconds (approx. 15
>>> minutes) don't help in the understanding. It's never said either how
>>> an RP should behave should the ID Token expire: should it
>>> re-authenticate (possibly using prompt=none and id_token_hint –note
>>> that the ID Token could have expired here, so having a definition of
>>> how the OP should validate it would be great) to check the user is
>>> still authenticated at the OP and possibly get a new ID Token?
>>>
>>> On Tue Feb 17 2015 at 03:45:31 Mike Jones
>>> <Michael.Jones at microsoft.com> wrote:
>>>
>>>> An updated version is attached. Changes were:
>>>>
>>>> 16-Feb-15 Added an optional id_token parameter to the logout_uri to
>>>> authenticate requests and differentiate between sessions, plus
>>>> related metadata values. Added that non-200 HTTP status codes can be
>>>> used when the logout fails. Clarified when post-logout redirection
>>>> to an RP occurs.
>>>>
>>>> I believe that this addresses the comments received to date.
>>>>
>>>> --
>>>> Mike
>>>>
>>>> -----Original Message-----
>>>> From: Openid-specs-ab
>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Mike
>>>> Jones
>>>> Sent: Sunday, February 15, 2015 11:03 PM
>>>> To: John Bradley; Torsten Lodderstedt
>>>> Cc: openid-specs-ab at lists.openid.net
>>>> Subject: Re: [Openid-specs-ab] OpenID Connect Logout using HTTP GET
>>>>
>>>>
>>>> I'm increasingly thinking that we should allow the OP to include the
>>>> ID Token for the RP as a query parameter in the logout request. I'm
>>>> thinking this for two reasons:
>>>>
>>>> 1. It would validate to the RP that the logout request is
>>>> legitimate.
>>>>
>>>> 2. It would tell the RP which session to log out, should multiple
>>>> users be logged in at the RP from the OP.
>>>>
>>>> I don't think we should make including the ID Token required, since
>>>> deployment circumstances will differ. In some cases, the extra
>>>> validation is important. In others, it isn't.
>>>>
>>>> If we do this, in the Discovery and Recovery metadata, we should
>>>> have the RP and the OP say whether the require and provide the ID
>>>> Token value as part of the logout message to the RP.
>>>>
>>>> --
>>>> Mike
>>>>
>>>> -----Original Message-----
>>>>
>>>> From: John Bradley [mailto:ve7jtb at ve7jtb.com]
>>>>
>>>> Sent: Sunday, February 15, 2015 11:34 AM
>>>>
>>>> To: Torsten Lodderstedt
>>>>
>>>> Cc: Thomas Broyer; Mike Jones; openid-specs-ab at lists.openid.net
>>>>
>>>> Subject: Re: [Openid-specs-ab] OpenID Connect Logout using HTTP GET
>>>>
>>>> Both
>>>>
>>>> forcing a user to logout of a RP might also be used as part of a
>>>> larger phishing attack, especially if the IdP returns the user to
>>>> the bad guys landing page by redirecting to the
>>>> post_logout_redirect_uri.
>>>>
>>>> That redirect URI needs to be registered but without authenticating
>>>> the RP via having a id_token for the user Bad RP A could log the
>>>> user out of all sessions and redirect the user to itself, without
>>>> the user currently being logged in.
>>>>
>>>> Without the id_token all the IdP can do is log the user out of all
>>>> sessions.
>>>>
>>>> Though when we start talking about IdP session management things get
>>>> a bit fuzzy, Many IdP will automatically log the user back in to a
>>>> RP if they are still logged in to the IdP, the IdP may not have any
>>>> real notion of state per RP connection.
>>>>
>>>> John B.
>>>>
>>>> On Feb 15, 2015, at 1:29 PM, Torsten Lodderstedt
>>>> <torsten at lodderstedt.net> wrote:
>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>>> against the RP or the user?
>>>>
>>>>>
>>>>
>>>>> Am 15.02.2015 um 17:22 schrieb John Bradley:
>>>>
>>>>>> It might be used as a denial of service via xsrf.
>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Openid-specs-ab mailing list
>>>>
>>>> Openid-specs-ab at lists.openid.net
>>>>
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab [1]
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab [1]
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab [1]
>>
>>
>>
>> Links:
>> ------
>> [1] http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> [2]
>> https://openid.net/specs/openid-connect-core-1_0.html#Authentication
>> [3]
>> https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidatio
>> n
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
More information about the Openid-specs-ab
mailing list