in oder to prevent such attacks, one could sign the inbound request
regards,
Torsten.
Am 19.04.2010 19:58, schrieb Eran Hammer-Lahav:
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?
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]
*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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
