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

Torsten Lodderstedt torsten at lodderstedt.net
Tue Feb 24 21:55:53 UTC 2015


No problem. If the authz of the logout is treated like any other (OAuth protected) request to a protected resource, you could also use OAuth POP instead of bearer tokens.

Am 24. Februar 2015 22:52:00 MEZ, schrieb Mike Jones <Michael.Jones at microsoft.com>:
>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.

-- 
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/e804a6b5/attachment.html>


More information about the Openid-specs-ab mailing list