Building identity on top of OAuth 2.0?

Allen Tom atom at yahoo-inc.com
Thu May 20 17:02:46 UTC 2010


Isn't this currently the case with the OpenID/Oauth Hybrid? If the RP has an
Access Token for the user, and the RP's login cookies are compromised, the
attacker will be able to use the RP as a proxy to the user's data on the OP.

Is there a new attack scenario that has been introduced that was not already
present in the existing OpenID 2.0/Hybrid?

Allen


On 5/19/10 11:06 PM, "Breno de Medeiros" <breno at google.com> wrote:

> I am saying that if someone steals the user login cookie for
> coolcalendar.com and coolcalendar also has a token to access the user
> contact data, it's pretty likely that the attacker will recover the
> contacts even if the login cookie is not the same token as the contact
> access token.
> 
> It is probably more effective as a security mechanism to restrict
> lifetime of access token in this case.
> 
> On Wednesday, May 19, 2010, Allen Tom <atom at yahoo-inc.com> wrote:
>> Hi Breno,
>> 
>> Can you describe the attack scenario with an example?
>> 
>> Thanks,
>> Allen
>> 
>> 
>> 
>> On 5/19/10 8:38 PM, "Breno de Medeiros" <breno at google.com> wrote:
>> 
>>> On Wed, May 19, 2010 at 20:36, David Recordon <recordond at gmail.com> wrote:
>>>> So because one thing is potentially insecure we should knowingly make two
>>>> things insecure? I'm not following your logic here. :-\
>>> 
>>> I am saying that the first insecure thing unlocks the second.
>>> 
>>>> 
>>>> On Wed, May 19, 2010 at 8:34 PM, Breno de Medeiros <breno at google.com>
>>>> wrote:
>>>>> 
>>>>> On Wed, May 19, 2010 at 20:28, David Recordon <recordond at gmail.com> wrote:
>>>>>> And given that the server would return one token good for both the
>>>>>> `openid`
>>>>>> and `calendar` scopes, leaking it via HTTP cookies would be bad. Thus in
>>>>>> my
>>>>>> proposal the access token remains secret and is useful for a variety of
>>>>>> scopes while the signature ­ sure another form of a "token" ­ can become
>>>>>> public and not compromise security.
>>>>> 
>>>>> Isn't it likely that compromising the logged-in state at the client
>>>>> exposes the data protected by the access token anyway, since the
>>>>> client has access to the token and therefore the data was probably
>>>>> imported and is available in the client?
>>>>> 
>>>>>> --David
>>>>>> 
>>>>>> On Wed, May 19, 2010 at 8:18 PM, Allen Tom <atom at yahoo-inc.com> wrote:
>>>>>>> 
>>>>>>> Whoa, I think it¹s premature to say that Yahoo supports OpenID Connect,
>>>>>>> but I would imagine that only a single Access Token would be returned
>>>>>>> to
>>>>>>> coolcalendar.com ­ the Access Token would presumably be good for both
>>>>>>> ³openid² and ³calendar² scope. Why would the OP want to return 2
>>>>>>> tokens?
>>>>>>> 
>>>>>>> Allen
>>>>>>> 
>>>>>>> 
>>>>>>> On 5/19/10 5:27 PM, "Dirk Balfanz" <balfanz at google.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Let's say I'm coolcalendar.com <http://coolcalendar.com> , and I want
>>>>>>> to
>>>>>>> "connect" one of my user's accounts to his Yahoo! account. I don't want
>>>>>>> to
>>>>>>> roll my own auth system, so I'm happy to see that Yahoo! supports
>>>>>>> OpenID
>>>>>>> Connect. To connect, I'll send the user over to Yahoo! with
>>>>>>> scope=openid%20yahoo-calendar. What I get back, in your proposal, is
>>>>>>> two
>>>>>>> different kinds of "tokens": the access token that my servers use to
>>>>>>> access
>>>>>>> Yahoo! and something I'll call "openid connect token" (which in your
>>>>>>> proposal comprises a few different parameters - user id, timestamp,
>>>>>>> signature, etc.) that browsers use (in form of a cookie) to access my
>>>>>>> own
>>>>>>> servers at coolcalendar.com <http://coolcalendar.com> .
>>>>>>> 
>>>>>>> Why do those two tokens look different? They serve the same purpose -
>>>>>>> authenticating access from a client to a server, so they should look
>>>>>>> the
>>>>>>> same.
>>>>>>> 
>>>>>>> Why should Yahoo! run different code to authenticate requests coming
>>>>>>> from
>>>>>>> my server than the code I'm running on my servers to authenticate
>>>>>>> requests
>>>>>>> coming from browsers - we have to solve the same task, so we should run
>>>>>>> the
>>>>>>> same code. It's simpler.
>>>> 



More information about the specs mailing list