Thanks, Eran. Will the security considerations section discuss this and recommend that auth servers warn the users of the potential phishing attack?
-- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav <[email protected]>wrote: > I don’t think there is much we can do either way to prevent these > phishing-like attacks with or without the client identifier. The key to > security here is the ability of the end-user to keep track of how it got > there, and based on that decide if they want to grant access to whoever sent > them to the authorization endpoint. This is the same problem with phishing – > the user ends up in a login page and unless they pay attention how they go > there (and where they are if its possible to assert), they will give the > attacker their password. > > > > If you don’t include the client identifier and won’t give them a hint > “John’s App wants access”, they will just get used to approving it without > the hint. At the end of the day, if there is value in approving such > unidentified clients, end-users will do it regardless of security. > > > > EHL > > > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Andrew Arnott > *Sent:* Tuesday, April 12, 2011 7:28 AM > *To:* OAuth WG ([email protected]) > *Subject:* [OAUTH-WG] client authentication for implicit grant type > > > > I brought this concern up about a year ago. Now reviewing the latest > drafts, I still have a concern with it. It is regarding the use of > client_id without a password. I agree with section 3, as included below: > > > > Section 3. Client Authentication > > The client identifier is not a secret, it is exposed to the resource > owner, and MUST NOT be used alone for client authentication. Client > authentication is accomplished via additional means such as a > matching client password. > > > > The above tells me (rightly so IMO) that considering the client_id alone > (without real authentication) is dangerous. Yet the Implicit Grant type > accepts a client_id, but no authentication: > > > > Section 4.2 Implicit Grant > > > > client_id > > REQUIRED. The client identifier as described in Section 3. > > Now here me: I am *not* advocating for a client_secret in this case. I > fully understand that some clients, particularly javascript widget clients > that are embedded in others' web pages, can't keep secrets. What I am > advocating is that clients that can't keep secrets shouldn't have IDs > either. This is a wide-open door for clients to obtain access to protected > user data by lying about their identity to authorization servers. They can > achieve this in either of two ways, given some popular client_id we'll > arbitrarily call 'facebook' that users are accustomed to authorizing access > to: > > 1. An evil client can redirect the user to the authorization endpoint, > requesting an implicit grant, and including client_id=facebook in the URL. > The authorization server may ask the user "Do you want to give Facebook > access?" along with (perhaps) a warning that most users won't know what to > do about (honestly, most technical users wouldn't know how to verify > either. > The user, who trusts Facebook, will click Accept, and offer whatever rogue > client was running on the page they were visiting the access that they > requested. > 2. In scenario 2, which is far worse, an evil client can redirect the > user to the authorization endpoint, requesting an implicit grant, and > including client_id=facebook in the URL. Same so far, but in this case, > the > authorization server sees that access has already been authorized by the > resource owner to this client in the past and immediately redirects back > with the requested access token, no user involvement whatsoever. Again, > the > client obtains access. > > Now, one might say to #2 that authorization servers shouldn't automatically > authorize implicit requests. That person would be absolutely right. I'm > concerned that enough clients will complain about the user experience though > that authorization servers will yield to them and begin auto-authorizing > these, justifying it by making the "limited" access tokens. No go. Either > you have protected data or you don't. > > To #1, there's no way that I can think of to properly educate the user to > be able to detect a phishing attack of this nature, such that if they see a > "do you want to authorize facebook?" when there is no facebook widget on the > page, that they should deny access. > > > > Between those two, I see only negative impact to including client_id in > implicit grant requests. Please, will someone either address my concerns > (tell me where I'm wrong) or remove that parameter from this grant type? > > > > Thanks for your time. > > > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
