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

mail at alfred-albrecht.net mail at alfred-albrecht.net
Mon Mar 2 20:55:17 UTC 2015

Not exactly. The logout_uri returns a callback function.

In our case, as we use JQuery it looks like that:


The function name is randomly generated by the OP for each RP and is
passed via query parameter during the logout call (e.g.

The RP parses the query parameter (callback) and returns it in the HTTP
body as function with the defined return value.


Am 02.03.2015 um 18:01 schrieb Mike Jones:
> 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.
> ---
> 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#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