I can see some federation scenarios where admins might want to configure auto-approvals for specific set of scopes for some set of users (essentially OpenID as a single sign-on mechanism with data transport). Putting this restriction directly into the standard as a MUST or SHOULD would mean that libraries would likely enforce checks (maybe without a configuration option) and make such deployments hard.
Maybe we should have a security considerations sections? On Wed, May 13, 2009 at 5:05 PM, Andrew Arnott <andrewarn...@gmail.com> wrote: > I would expect a decent OP to consider that it goes without saying that > checkid_immediate wouldn't have a reasonable OAuth token authorizing > scenario and block it. So I agree it's good to call it out in the spec. > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > > On Tue, May 12, 2009 at 10:06 PM, Allen Tom <a...@yahoo-inc.com> wrote: >> >> Hi Luke, >> >> I don't think there's a session fixation issue with Hybrid, but I believe >> that several individuals raised concerns regarding auto-approval of OAuth >> tokens using regular OAuth, which is essentially the same thing as >> checkid_immediate mode in Hybrid. >> >> Is there really a reason why an RP would need the OAuth token returned in >> a checkid_immediate response if the user had previously authorized one on an >> earlier visit? >> >> Allen >> >> >> Luke Shepard wrote: >> >> (hijacking thread a bit) >> >> Allen- >> >> If I understand it correctly, the OAuth security issue doesn’t affect the >> hybrid spec in the same way. >> >> With the OAuth session fixation vulnerability, the problem comes if the >> attacker does the following: >> >> Request a request token by pretending to request access >> Force the user to go to a url using that request token >> Muah! Calculate what the return_to url would have been, and use the >> pre-known request token to gain access to the user’s account info. >> >> In the OAuth hybrid flow, there is no pre-registered request token; >> instead, the token is returned, securely, in the URL. It is protected by the >> fact that OpenID requires the realm to match the return_to, and many >> providers can require that the Oauth request realm also match the OpenID >> realm. In this flow, there’s no way for the attacker to intercept the >> request_token before it makes its way back to the correct user. >> >> Perhaps the problem is more subtle than I understood, but I just want to >> make sure I’m clear on the issues. >> >> On 5/12/09 9:48 PM, "Allen Tom" <a...@yahoo-inc.com> wrote: >> >> Hi Nat, >> >> Here you go: >> >> >> http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html >> >> We might need to revise the spec to not support checkid_immediate for >> the Hybrid flow, becuase auto-issuing OAuth access tokens is probably a >> bad thing, in light of the recent OAuth security issue. >> >> Allen >> >> >> >> >> >> Nat Sakimura wrote: >> > Hi. >> > >> > Where can I find the most current version of OpenID / OAuth hybrid spec >> > draft? >> > I would like to look at it to see if I can borrow as much from the >> > draft for what I am thinking right now. >> > >> > >> >> _______________________________________________ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> >> >> >> _______________________________________________ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> > > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
