Re: [OAUTH-WG] Issue: 'username' parameter proposal

On Mon, Apr 19, 2010 at 10:58 AM, Eran Hammer-Lahav <eran@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:uidude@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 <eran@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" <uidude@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 bob@IDP.com.
>    2. Mary (his wife) is logged into IDP on the same computer as
>    mary@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 <eran@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
>
>
>
>
>