On Thu, May 20, 2010 at 10:14, Dirk Balfanz <[email protected]> wrote: > On Thu, May 20, 2010 at 10:10 AM, David Recordon <[email protected]> > wrote: >> >> No, my point is that exposing the access token (which is more powerful) by >> default is a poor idea. > > Your proposal includes an access token (it doesn't call it that, but that's > what it is) that is, when set as a cookie over non-SSL, exposed. > Whether or not access tokens are exposed is an orthogonal issue to what they > look like. I'm arguing for making all access tokens look the same. I'm not > arguing for exposing them.
+ 1 And I am additionally making the point that, if the token for auth is separate (even if of the same type) as the API access token, some glue needs to bind them in the response. > Dirk. > >> >> On Thu, May 20, 2010 at 10:07 AM, Breno de Medeiros <[email protected]> >> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> wrote: >>> >>> Hi Breno, >>> >>> >>> >>> Can you describe the attack scenario with an example? >>> >>> >>> >>> Thanks, >>> >>> Allen >>> >>> >>> >>> >>> >>> >>> >>> On 5/19/10 8:38 PM, "Breno de Medeiros" <[email protected]> wrote: >>> >>> >>> >>>> On Wed, May 19, 2010 at 20:36, David Recordon <[email protected]> >>> >>>> 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 >>> >>>>> <[email protected]> >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> On Wed, May 19, 2010 at 20:28, David Recordon >>> >>>>>> <[email protected]> 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 <[email protected]> >>> >>>>>>> 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" <[email protected]> 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) _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
