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. >>>> _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
