Building identity on top of OAuth 2.0?

David Recordon recordond at gmail.com
Thu May 20 17:10:58 UTC 2010


No, my point is that exposing the access token (which is more powerful) by
default is a poor idea.

On Thu, May 20, 2010 at 10:07 AM, Breno de Medeiros <breno at google.com>wrote:

> Yes, that's my point.
>
> David's point is that we need two tokens to defend against these scenarios.
>
> On Thu, May 20, 2010 at 10:02, Allen Tom <atom at yahoo-inc.com> wrote:
> > 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.
> >>>>>
> >
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100520/e08fe4ca/attachment.html>


More information about the specs mailing list