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

[Torsten Lodderstedt <[e-mail]>]

In my experiences, such a review takes much longer than a few minutes.

I think the whole specification should be subject to a comprehensive and 
in-depth security analysis (threat modeling, counter measures and so 
on). So why not adding this parameter and examine its implications in 
this context?

regards,
Torsten.

Am 20.04.2010 19:23, schrieb Eran Hammer-Lahav:
>
> I'm not aware of anyone arguing against this feature. The only issue 
> is a full security review before we add it to the spec. If one of the 
> security experts here can spend a few minutes to review this, we can 
> move forward and add it to the draft.
>
> EHL
>
> *From:* Joseph Smarr [mailto:[e-mail]]
> *Sent:* Tuesday, April 20, 2010 9:36 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Evan Gilbert; OAuth WG
> *Subject:* Re: [OAUTH-WG] Issue: 'username' parameter proposal
>
> 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 
> <http://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] <mailto:[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] 
> <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] <mailto:[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]
>     <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] <mailto:[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]
>     <http://[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]
>               <http://[e-mail]>.
>            2. Mary (his wife) is logged into IDP on the same computer
>               as [e-mail] <http://[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] <http://[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] <http://[e-mail]>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>