This is part of the delegation flows so username should be just fine... EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eve Maler Sent: Wednesday, April 21, 2010 4:43 PM To: OAuth WG Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal Tacking this response to the end of the thread for lack of a better place to do it: The name "username" seems not quite apt in the case of an autonomous client that isn't representing an end-user. Would "identifier" be better? (Actually, it sort of reminds me of SAML's "SessionIndex"...) Or would the parameter be reserved for user-delegation flows? Speaking of autonomous clients, Section 2.2 -- among possibly other places -- states that an autonomous client is also the resource owner, but that's not always the case, is it? The client might be seeking access on behalf of itself. (FWIW, I made roughly this same comment on David's first draft on March 21, and he agreed with my suggested fix at the time.) Eve On 21 Apr 2010, at 2:30 PM, Torsten Lodderstedt wrote: Am 20.04.2010 20:59, schrieb Eran Hammer-Lahav: Because the rest of the spec did receive extensive review from both early adopters and from the previous drafts it borrowed from. Nothing so far is a new concept. The concept of an identity is new in OAuth, and while offers important benefits, should not be added to the spec when there are actual security concerns around it. My impression is that the specification has undergone significant changes since its first version and cannot be compared to its predecessor in terms of security. Let me give you some examples. I wonder if anyone security reviewed the introduction of refresh tokens to the User Agent Flow? From my point of view, refresh tokens are dangerous in this flow. First of all, where should a JavaScript client store this token securely? If someone is able to steal the token, it can use it to obtain access tokens. Steps: 1) legitimate client is granted access by the end user 2) client stores refresh token in local storage (?) 3) malicious software reads refresh token from local storage 4) malicious software obtains access token from the authorization server (no client secret required) 5) malicious software uses token or sends it to a central storage for further abuse Second, the immediate mode has been introduced to the User Agent flow recently. I don't know exactly but my feeling is that a malicious software can steal tokens. Steps: 1) malicious software initiated authorization flow using immediate=true and a stolen client_id 2) Assuming this client has been granted access by the end user of the particular computer, the authorization server directly respondes with tokens w/o user interaction. The user does not realize what is happening. 3) malicious software uses token or sends it to a central storage for further abuse The only countermesure I see is the redirect URL verification, which seams to be optional: "If the client has previously registered a redirection URI with the authorization server". I raised a specific issue that was not addressed. Brian seems to have other concerns. Other posts on the thread indicated a need for such an concept. We use such parameters, too. I think, from a security standpoint, the problem is much more the immediate parameter then the username parameter. If the username is modified by an attacker, the user should see the username in authentication or authorization dialogs. So he/her can react. That's not the case in immediate mode, so there are only technical ways to prevent username modifications, HTTPS or signatures. I don't like the policy of add-first-discuss-later. I don't like it either. But sometimes it is more efficient to make progress and discuss such aspects in-depth when reaching milestones. regards, Torsten. EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Tuesday, April 20, 2010 11:55 AM To: Eran Hammer-Lahav Cc: jsm...@stanfordalumni.org<mailto:jsm...@stanfordalumni.org>; OAuth WG Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal 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:jsm...@gmail.com] 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...@hueniverse.com<mailto:e...@hueniverse.com>> 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:uid...@google.com<mailto:uid...@google.com>] 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...@hueniverse.com<mailto: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<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<mailto: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<http://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<http://b...@idp.com/>. 2. Mary (his wife) is logged into IDP on the same computer as m...@idp.com<http://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<http://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<http://OAuth@ietf.org/> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth Eve Maler e...@xmlgrrl.com<mailto:e...@xmlgrrl.com> http://www.xmlgrrl.com/blog
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
