I like the idea of issuing a short lived Access Token that has to be
periodically refreshed using checkid_immdiate , implying that the user
needs to be signed-in to both the OP (and presumably the RP) in order
to refresh the credentials. This makes a lot of sense from a security
perspective, and helps to mitigate the scenario where an RP that the
user doesn't actively use has persistent access to user's data.
However, I believe that the conventional use case for OAuth is to issue
persistent credentials to the RP to allow the RP to access services on
behalf of the user, independent of the user having an active browser
session at either the OP or RP.
Allen
Luke Shepard wrote:
As I suggested, an OP may want to give an updated session via
checkid-immediate. Facebook Connect does this, and it seems like a legit use
case to me.
________________________________
From: Andrew Arnott <andrewarn...@gmail.com>
To: Allen Tom <a...@yahoo-inc.com>
Cc: Luke Shepard; OpenID Specs Mailing List <specs@openid.net>
Sent: Wed May 13 17:05:00 2009
Subject: Re: Does OAuth security vulnerability affect OpenID/OAuth hybrid?
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<mailto: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:
1. Request a request token by pretending to request access
2. Force the user to go to a url using that request token
3. 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<http://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://specs@openid.net>
http://openid.net/mailman/listinfo/specs
_______________________________________________
specs mailing list
specs@openid.net<mailto:specs@openid.net>
http://openid.net/mailman/listinfo/specs
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
