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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
