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