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
