Building identity on top of OAuth 2.0?

[Breno de Medeiros]

Stepping back and assuming that it is a goal to allow for compromise
of the login cookie at the client _not_ imply compromise of the access
token.

In this case, it is not sufficient to have two separate tokens. The
client will need to adopt additional security measures, such as to
redirect from the return URL in such a way as to strip the access
token from the URL.


On Wed, May 19, 2010 at 23:06, 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.
>>>>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)