On Tue, Apr 12, 2011 at 7:27 AM, Andrew Arnott <andrewarn...@gmail.com> wrote: > 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.
Maybe this is obvious, but none of these scenarios are that easy to exploit in practice. If evil client presents "facebook" as a client ID then it can only use a redirect URI that matches the one registered by the real Facebook. Unless an open redirector on Facebook can be exploited (if matching rules are too lax), evil client cannot grab the response. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
