[Openid-specs-ab] OpenID Connect Logout using HTTP GET

Mike Jones Michael.Jones at microsoft.com
Mon Mar 2 17:01:28 UTC 2015

So actually, it seems that the logout_uri returning either a 200 or an error code would be compatible with your approach.  Is that correct?

				-- Mike

-----Original Message-----
From: mail at alfred-albrecht.net [mailto:mail at alfred-albrecht.net] 
Sent: Monday, March 02, 2015 5:49 AM
To: openid-specs-ab at lists.openid.net; Mike Jones
Subject: Re: [Openid-specs-ab] OpenID Connect Logout using HTTP GET

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.


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#Authenticatio
>>> n [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#IDTokenValidat
>> i
>> 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#IDTokenValidati
>> o
>> 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