At the very least, the security considerations section should say that
the OP should have obtained the user's consent to authorize the Access
Token before issuing it to the RP. This means that the Access Token
should not be returned via checkid_immediate unless the user had
approved the token on a previous checkid_setup request.
There are federation scenarios (ie: close partnerships, etc) where user
consent might not be necessary, so obtaining the user's consent is a
SHOULD (or STRONGLY RECOMMENDED) rather than a MUST.
Allen
Breno de Medeiros wrote:
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
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
