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

[Joseph Smarr <[e-mail]>]

Just to add some more context from experience, this "two users getting mixed
together" problem happens a lot in practice, esp. when you have a mix of
server-side and client-side auth. For instance, we saw this in our Facebook
Connect integration in Plaxo--normally the user connects and Plaxo stores
their session key in our databases, so when the user returns and logs in as
plaxo-user-123, we look it up and know that he's also facebook-user-456. But
some of Facebook Connect's UI widgets just look at the browser cookies on
facebook.com, where facebook-user-789 may be currently logged in (happens
all the time with shared computers at home). Thus we often had pages that
pulled some Facebook info server-side (as facebook-user-456) and some
client-side (as facebook-user-789) and it was very confusing and potentially
harmful (e.g. easy to accidentally post a story to the wrong account). The
solution would be for Plaxo to be able to pass facebook-user-456 down to the
JavaScript library, so it wouldn't just "silently auth" as a different
user--presumably, it would just treat it as if no one was logged into
facebook, if the passed-in user is not logged in. I think this is what Evan
is proposing we enable for OAuth, especially if we want it to work
client-side with immediate-mode (which I think we do).

Another related example of this problem we saw was with our photo-uploader
plug-in inside Picasa Desktop for sharing photos on Plaxo. During the upload
flow, it embeds a web browser, which lets you log in as plaxo-user-123, but
when it's done uploading, it opens a default web browser, where you might be
logged in as plaxo-user-456, leading again to a confusing mix-up of
identities. We solved this by appending the session-info of the user from
the embedded web browser on the URL of the main browser that gets opened, so
it can clobber the session as needed and maintain continuity of session.

Hope these experiences provide some useful and concrete context for
evaluating whether/how to support a username parameter in OAuth.

Thanks, js

On Tue, Apr 20, 2010 at 8:08 AM, Eran Hammer-Lahav <[e-mail]>wrote:

> This attack is why the flow requires the client to present the callback it
> used again when getting the token.
>
>
>
> EHL
>
>
>
>
>
> *From:* Evan Gilbert [mailto:[e-mail]]
> *Sent:* Monday, April 19, 2010 5:17 PM
>
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Issue: 'username' parameter proposal
>
>
>
>
>
> On Mon, Apr 19, 2010 at 10:58 AM, Eran Hammer-Lahav <[e-mail]>
> 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:[e-mail]]
> *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-mail]>
> 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" <[e-mail]> 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 [e-mail].
>    2. Mary (his wife) is logged into IDP on the same computer as
>    [e-mail]
>    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-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>