<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Luke,<br>
<br>
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.<br>
<br>
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?<br>
<br>
Allen<br>
<br>
<br>
Luke Shepard wrote:
<blockquote cite="mid:C62FA1A3.BCCA%25lshepard@facebook.com" type="cite">
<title>Does OAuth security vulnerability affect OpenID/OAuth hybrid?</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">(hijacking thread a bit)<br>
<br>
Allen-<br>
<br>
If I understand it correctly, the OAuth security issue doesn’t affect
the hybrid spec in the same way.<br>
<br>
With the OAuth session fixation vulnerability, the problem comes if the
attacker does the following:<br>
<br>
</span></font>
<ol>
<li><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Request a request token by pretending to
request access
</span></font></li>
<li><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Force the user to go to a url using that
request token
</span></font></li>
<li><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">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.<br>
</span></font></li>
</ol>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
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.<br>
<br>
Perhaps the problem is more subtle than I understood, but I just want
to make sure I’m clear on the issues.<br>
<br>
On 5/12/09 9:48 PM, "Allen Tom" <<a moz-do-not-send="true"
href="atom@yahoo-inc.com">atom@yahoo-inc.com</a>> wrote:<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Hi Nat,<br>
<br>
Here you go:<br>
<br>
<a moz-do-not-send="true"
href="http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html">http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html</a><br>
<br>
We might need to revise the spec to not support checkid_immediate for<br>
the Hybrid flow, becuase auto-issuing OAuth access tokens is probably a<br>
bad thing, in light of the recent OAuth security issue.<br>
<br>
Allen<br>
<br>
<br>
<br>
<br>
<br>
Nat Sakimura wrote:<br>
> Hi.<br>
><br>
> Where can I find the most current version of OpenID / OAuth hybrid
spec draft?<br>
> I would like to look at it to see if I can borrow as much from the<br>
> draft for what I am thinking right now.<br>
><br>
> <br>
<br>
_______________________________________________<br>
specs mailing list<br>
<a moz-do-not-send="true" href="specs@openid.net">specs@openid.net</a><br>
<a moz-do-not-send="true"
href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a><br>
<br>
</span></font></blockquote>
</blockquote>
<br>
</body>
</html>