No, my point is that exposing the access token (which is more powerful) by default is a poor idea.<div><br><div class="gmail_quote">On Thu, May 20, 2010 at 10:07 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Yes, that's my point.<br>
<br>
David's point is that we need two tokens to defend against these scenarios.<br>
<div><div></div><div class="h5"><br>
On Thu, May 20, 2010 at 10:02, Allen Tom <<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>> wrote:<br>
> Isn't this currently the case with the OpenID/Oauth Hybrid? If the RP has an<br>
> Access Token for the user, and the RP's login cookies are compromised, the<br>
> attacker will be able to use the RP as a proxy to the user's data on the OP.<br>
><br>
> Is there a new attack scenario that has been introduced that was not already<br>
> present in the existing OpenID 2.0/Hybrid?<br>
><br>
> Allen<br>
><br>
><br>
> On 5/19/10 11:06 PM, "Breno de Medeiros" <<a href="mailto:breno@google.com">breno@google.com</a>> wrote:<br>
><br>
>> I am saying that if someone steals the user login cookie for<br>
>> <a href="http://coolcalendar.com" target="_blank">coolcalendar.com</a> and coolcalendar also has a token to access the user<br>
>> contact data, it's pretty likely that the attacker will recover the<br>
>> contacts even if the login cookie is not the same token as the contact<br>
>> access token.<br>
>><br>
>> It is probably more effective as a security mechanism to restrict<br>
>> lifetime of access token in this case.<br>
>><br>
>> On Wednesday, May 19, 2010, Allen Tom <<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>> wrote:<br>
>>> Hi Breno,<br>
>>><br>
>>> Can you describe the attack scenario with an example?<br>
>>><br>
>>> Thanks,<br>
>>> Allen<br>
>>><br>
>>><br>
>>><br>
>>> On 5/19/10 8:38 PM, "Breno de Medeiros" <<a href="mailto:breno@google.com">breno@google.com</a>> wrote:<br>
>>><br>
>>>> On Wed, May 19, 2010 at 20:36, David Recordon <<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>> wrote:<br>
>>>>> So because one thing is potentially insecure we should knowingly make two<br>
>>>>> things insecure? I'm not following your logic here. :-\<br>
>>>><br>
>>>> I am saying that the first insecure thing unlocks the second.<br>
>>>><br>
>>>>><br>
>>>>> On Wed, May 19, 2010 at 8:34 PM, Breno de Medeiros <<a href="mailto:breno@google.com">breno@google.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>> On Wed, May 19, 2010 at 20:28, David Recordon <<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>> wrote:<br>
>>>>>>> And given that the server would return one token good for both the<br>
>>>>>>> `openid`<br>
>>>>>>> and `calendar` scopes, leaking it via HTTP cookies would be bad. Thus in<br>
>>>>>>> my<br>
>>>>>>> proposal the access token remains secret and is useful for a variety of<br>
>>>>>>> scopes while the signature sure another form of a "token" can become<br>
>>>>>>> public and not compromise security.<br>
>>>>>><br>
>>>>>> Isn't it likely that compromising the logged-in state at the client<br>
>>>>>> exposes the data protected by the access token anyway, since the<br>
>>>>>> client has access to the token and therefore the data was probably<br>
>>>>>> imported and is available in the client?<br>
>>>>>><br>
>>>>>>> --David<br>
>>>>>>><br>
>>>>>>> On Wed, May 19, 2010 at 8:18 PM, Allen Tom <<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>> wrote:<br>
>>>>>>>><br>
>>>>>>>> Whoa, I think itıs premature to say that Yahoo supports OpenID Connect,<br>
>>>>>>>> but I would imagine that only a single Access Token would be returned<br>
>>>>>>>> to<br>
>>>>>>>> <a href="http://coolcalendar.com" target="_blank">coolcalendar.com</a> the Access Token would presumably be good for both<br>
>>>>>>>> ³openid² and ³calendar² scope. Why would the OP want to return 2<br>
>>>>>>>> tokens?<br>
>>>>>>>><br>
>>>>>>>> Allen<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> On 5/19/10 5:27 PM, "Dirk Balfanz" <<a href="mailto:balfanz@google.com">balfanz@google.com</a>> wrote:<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> Let's say I'm <a href="http://coolcalendar.com" target="_blank">coolcalendar.com</a> <<a href="http://coolcalendar.com" target="_blank">http://coolcalendar.com</a>> , and I want<br>
>>>>>>>> to<br>
>>>>>>>> "connect" one of my user's accounts to his Yahoo! account. I don't want<br>
>>>>>>>> to<br>
>>>>>>>> roll my own auth system, so I'm happy to see that Yahoo! supports<br>
>>>>>>>> OpenID<br>
>>>>>>>> Connect. To connect, I'll send the user over to Yahoo! with<br>
>>>>>>>> scope=openid%20yahoo-calendar. What I get back, in your proposal, is<br>
>>>>>>>> two<br>
>>>>>>>> different kinds of "tokens": the access token that my servers use to<br>
>>>>>>>> access<br>
>>>>>>>> Yahoo! and something I'll call "openid connect token" (which in your<br>
>>>>>>>> proposal comprises a few different parameters - user id, timestamp,<br>
>>>>>>>> signature, etc.) that browsers use (in form of a cookie) to access my<br>
>>>>>>>> own<br>
>>>>>>>> servers at <a href="http://coolcalendar.com" target="_blank">coolcalendar.com</a> <<a href="http://coolcalendar.com" target="_blank">http://coolcalendar.com</a>> .<br>
>>>>>>>><br>
>>>>>>>> Why do those two tokens look different? They serve the same purpose -<br>
>>>>>>>> authenticating access from a client to a server, so they should look<br>
>>>>>>>> the<br>
>>>>>>>> same.<br>
>>>>>>>><br>
>>>>>>>> Why should Yahoo! run different code to authenticate requests coming<br>
>>>>>>>> from<br>
>>>>>>>> my server than the code I'm running on my servers to authenticate<br>
>>>>>>>> requests<br>
>>>>>>>> coming from browsers - we have to solve the same task, so we should run<br>
>>>>>>>> the<br>
>>>>>>>> same code. It's simpler.<br>
>>>>><br>
><br>
><br>
<br>
<br>
<br>
</div></div><div><div></div><div class="h5">--<br>
--Breno<br>
<br>
+1 (650) 214-1007 desk<br>
+1 (408) 212-0135 (Grand Central)<br>
MTV-41-3 : 383-A<br>
PST (GMT-8) / PDT(GMT-7)<br>
</div></div></blockquote></div><br></div>