But that wasn't the question... it was whether the two are closely related (as in, should be defined in the same specification) and likely to be used together.
EHL From: Luke Shepard [mailto:lshep...@facebook.com] Sent: Wednesday, May 26, 2010 7:29 AM To: Allen Tom Cc: Eran Hammer-Lahav; Dick Hardt; OAuth WG Subject: Re: [OAUTH-WG] 'immediate' without identity This is a legitimate concern. One other possible way to prevent this issue is for the client to interpret the response, clear state, and refresh the page. This is the suggested way that many Connect sites handle the situation. I don't disagree that it may be nice to allow the client to pass a username for verification. I think that it should not be required, as responsible clients can do the right thing. Requiring a username prevents a whole class of possible use cases - most notably, single sign on when you don't currently know the user at all. On May 25, 2010, at 6:42 PM, Allen Tom wrote: Yahoo's security team has concerns regarding the immediate mode and shared computers. Consider the case where a browser based JS app is running in a browser tab with credentials belonging to a particular user. While the app is still running, the original user lets a friend borrow the browser. The friend opens another tab, logs the original user out of the Service Provider, and then logs in as different user using the friend's account. At this point - the app is still running as the original user a different tab. If the app's credentials expire, it could attempt an immediate request to refresh them - which could then return the credentials belonging to the 2nd user. Since this is a JS app - the data that belongs to the first user is already loaded, so the app could start co-mingling the data between the two users. At Yahoo, we call this scenario "crossing the streams" - and that's always a really bad thing. This scenario could be really disastrous if the SP has a login CSRF vulnerability - meaning that an attacker can CSRF the victim's browser into logging in with the attacker's account. This vulnerability would result in the victim's data mixing with the Attacker. One possible way to prevent this issue is for the client to pass the user's identifier (or access token/refresh token/etc) in the immediate request. Allen On 5/24/10 1:05 PM, "Eran Hammer-Lahav" <e...@hueniverse.com<x-msg://77/e...@hueniverse.com>> wrote: I am more interested in how you plan to address the (long term) security and privacy issue: who is responsible to prevent one user in getting an access token for another in a shared computer environment. As long as the user goes to facebook.com<http://facebook.com>, you show they who is logged in clearly, so if it is not them, they can log out. But using immediate without a username, it sounds to me like you expect the client to do the right thing. Is this how you plan to address this? Ask the client to find out whose access token it got, display it to the user, and allow them to correct this? Especially given that at this point the client account is already "paired" with the access token. EHL On 5/24/10 12:44 PM, "Luke Shepard" <lshep...@facebook.com<x-msg://77/lshep...@facebook.com>> wrote: Suppose the client does not have a username - say, because the cookie expired. What is the appropriate behavior? Would you require the client to spawn a popup or redirect to a full page auth every time a user revisits their site? This doesn't make sense. Under what circumstances do you think the client gives an access token that belongs to another user? If the user is logged into the service provider, then they can get that access token anyway by just visiting the service provider ... On May 24, 2010, at 11:18 AM, Dick Hardt wrote: > > On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote: > >> >> >>> -----Original Message----- >>> From: Dick Hardt [mailto:dick.ha...@gmail.com] >>> Sent: Monday, May 24, 2010 7:35 AM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG (oauth@ietf.org<x-msg://77/oauth@ietf.org>) >>> Subject: Re: [OAUTH-WG] 'immediate' without identity >>> >>> You were looking for use cases for immediate without identity. >>> >>> I agree that *if* the client does know the user, then it should tell the >>> server. >>> Are you saying that if the client does not know the user it should not use >>> immediate? >> >> I think the server should reject an immediate request without a username. >> Otherwise the server will be giving the client an access token that belongs >> to another user. > > Now I understand. I agree. > > -- Dick > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<x-msg://77/OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth ________________________________ _______________________________________________ OAuth mailing list OAuth@ietf.org<x-msg://77/OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
