Building identity on top of OAuth 2.0?

[Allen Tom]

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.
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> --Breno
>>> 
>>> +1 (650) 214-1007 desk
>>> +1 (408) 212-0135 (Grand Central)
>>> MTV-41-3 : 383-A
>>> PST (GMT-8) / PDT(GMT-7)
>> 
>> 
> 
>