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

John Bradley ve7jtb at ve7jtb.com
Sat Feb 21 13:38:54 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150221/65c9af5f/attachment.html>


More information about the Openid-specs-ab mailing list