On Mon, Apr 19, 2010 at 10:58 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> Thanks. That makes sense. > > > > My concern is that the client will ask for a specific username but an > attacker will change that request before it hits the server. The server then > asks the (wrong) user to authenticate and returns a token. The client has no > way of knowing it got an access token for the wrong user. Does requiring > that the server returns the token with the username solves this? Is this a > real issue? > This particular attack wasn't of concern to me, for a few of reasons: - The request is HTTPS, hard to modify the request before it hits the server - There are probably other, more dangerous attacks if you can modify request parameters (for example, you can modify the client_id and get the user to authorize the wrong app) I'm willing to be convinced otherwise > > > I have no objections to this proposal but wanted to see some discussion and > support from others before adding it to the spec. > > > > EHL > > > > *From:* Evan Gilbert [mailto:uid...@google.com] > *Sent:* Monday, April 19, 2010 10:06 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG > > *Subject:* Re: [OAUTH-WG] Issue: 'username' parameter proposal > > > > User 1 is logged into Client site > > User 2 is logged into IDP site > > > > This can happen quite frequently, as client sites often have long-lived > cookies and may only be visited by one user on a shared computer. > > > > Right now client site has no way to ask for a token for User 1, and end > result will be that User 1 starts seeing User 2's data. > > > > On Mon, Apr 19, 2010 at 8:37 AM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > How can they both be logged in? I have never seen a case where two users > can be both logged into to the same service at the same time... > > EHL > > > > > On 4/19/10 8:33 AM, "Evan Gilbert" <uid...@google.com> wrote: > > More details on this enhancement. > > Goal: Make sure you get an access token for the right user in immediate > mode. > > Use case where we have problems if we don't have username parameter: > > 1. Bob is logged into a web site as b...@idp.com. > 2. Mary (his wife) is logged into IDP on the same computer as > m...@idp.com > 3. A request is made to get an access token via the User-Agent flow in > immediate mode (or with any redirect without prompting the user) > 4. -ob now has an access token for Mary and (posts activities, > schedules events, gets contacts) as Mary > 5. Hilarity ensues > > > Secondary goal: Provide a hint for non-immediate mode > > On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > Evan Gilbert proposed a 'username' request parameter to allow the client to > limit the end user to authenticate using the provided authorization server > identifier. The proposal has not been discussed or supported by others, and > has not received a security review. > > Proposal: Obtain further discussion and support from others, as well as a > security review of the proposal. Otherwise, do nothing. > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
