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

Mike Jones Michael.Jones at microsoft.com
Tue Feb 24 21:52:00 UTC 2015


Eventually, I suspect that we want to be able to use channel binding IDs as session IDs.  These are not bearer tokens.  We should keep that possibility in mind when architecting this in the short term.

                                                                -- Mike

From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Torsten Lodderstedt
Sent: Saturday, February 21, 2015 6:30 AM
To: John Bradley; Thomas Broyer
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] OpenID Connect Logout using HTTP GET

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<mailto: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<mailto: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 crede ntials (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 redir ect_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). Explain ing 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<mailto: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<mailto: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<mailto: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<mailto: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/20150224/7dacce21/attachment-0001.html>


More information about the Openid-specs-ab mailing list