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

Torsten Lodderstedt torsten at lodderstedt.net
Sat Feb 21 14:30:20 UTC 2015


Hi all,

sid looks like a bearer token (handle). I therefore don't see the need for further cryptographical protection.

In my opinion, it should be at the discretion of the RP whether and how to authorize logout requests (and also the format of respective tokens). I would therefore suggest to turn the model around. Why not let the RP create a suitable token and send it to the OP as part of the authentication process? The same way the nonce collates requests of the authentication process, this token would authorize acces to the RP's logout endpoint (for a certain session). 

What do you think? 

kind regards, 
Torsten. 

Am 21. Februar 2015 14:38:54 MEZ, schrieb John Bradley <ve7jtb at ve7jtb.com>:
>From a security point of view sending did in a JWT would be best,
>however the size of a asymmetrically signed JWT is not insignificant
>when multiplied by the RP to be logged out.   The biggest problem with
>this logout method is that tend to close the page after logging out.
>
>The larger the message the less likely they all will work. 
>
>Perhaps someone can produce some performance comparisons to help us
>make a decision. 
>
>John B. 
>
>Sent from my iPhone
>
>> On Feb 21, 2015, at 9:52 AM, Thomas Broyer <t.broyer at gmail.com>
>wrote:
>> 
>> Could you please add "Security Considerations" section?
>> 
>> IMO, "sid" should be required, and RPs MUST validate the "sid" claim
>and not only rely on the sent credentials (generally a cookie or set of
>cookies). Failing to do that leaves the door open to CSRF logging out
>users from third-party RPs (possibly a competitor). Sure the impact is
>"limited", in the sense those RPs could probably log the user in
>transparently the next time they come in (that depends on the OP
>though, possibly some user configuration at the OP; or the RP if they
>use the 'prompt' parameter), but it's still a threat (the attacker
>could log you out every few minutes, and you' likely never blame them,
>but rather the victim RP).
>> 
>> Also, quite obviously the "sid" claim should be kept as private as
>possible (see my previous mails in this thread); but as it's returned
>in the id_token and that one is sent as id_token_hint to
>authorization_endpoints and end_session_endpoints, or even right to the
>redirect_uri… Or maybe the OP SHOULD "revoke" the "sid" in this case
>(and issue a new one to the redirect_uri when received at the
>authorization_endpoint). But there's still a "risk" if the RP doesn't
>use HTTPS (redirection to the OP with the id_token_hint could be easily
>intercepted; or to the RP when using an id_token response_type)
>> It should also be "sufficiently unique" as to not be discoverable (or
>subject to brute force; see CSRF attack scenario above).
>> 
>> IMO, the logout_uri should receive some crypto material (signature or
>encryption) he can verify to validate that the caller is the OP, and
>that parameter should have a short validity timeframe and/or include
>some sort of "nonce" to prevent replay attacks. It could just be a JWT
>(JWS/JWE) including the "sid" you propose as a claim, along with "iat",
>"exp", and/or a "jti".
>> If this has been rejected for any reason, please make it public
>somewhere (and ideally even add it in an appendix). Explaining the
>"why" is almost as important as describing the "how" of the settled-on
>solution in any spec (why that thing is a MUST, or a SHOULD, why has
>this been designed that way and not another, etc.)
>> 
>>> On Sat Feb 21 2015 at 01:38:02 Mike Jones
><Michael.Jones at microsoft.com> wrote:
>>> A third iteration of the proposed OpenID Connect spec on logout
>using HTTP GET is attached.  (It’s now a two-pager.) This incorporates
>the results of the useful discussion on Thursday’s call.  Keep those
>cards and letters coming!
>>> 
>>>  
>>> 
>>> Changes were:
>>> 
>>> ·         Replaced the optional id_token parameter with an optional
>sid (Session ID) parameter.
>>> 
>>> ·         Enabled the use of iframes with nested images or iframes
>to achieve downstream logouts.
>>> 
>>>  
>>> 
>>>                                                             -- Mike
>>> 
>>>  
>>> 
>>> _______________________________________________
>>> 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
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Openid-specs-ab mailing list
>Openid-specs-ab at lists.openid.net
>http://lists.openid.net/mailman/listinfo/openid-specs-ab

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150221/1287df7a/attachment-0001.html>


More information about the Openid-specs-ab mailing list