Subject: [OAUTH-WG] client authentication for implicit grant type

From: Andrew Arnott <[email-masked]>
Date: Tue, 12 Apr 2011 07:27:41 -0700

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 12 Apr 2011 07:48:07 -0700

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-masked] [mailto:[email-masked]] On Behalf Of Andrew Arnott
Sent: Tuesday, April 12, 2011 7:28 AM
To: OAuth WG ([email-masked])
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:

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:

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

---

From: Andrew Arnott <[email-masked]>
Date: Tue, 12 Apr 2011 08:30:13 -0700

Thanks, Eran.  Will the security considerations section discuss this and
recommend that auth servers warn the users of the potential phishing attack?

On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav <[email-masked]>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-masked] [mailto:[email-masked]] *On Behalf
> Of *Andrew Arnott
> *Sent:* Tuesday, April 12, 2011 7:28 AM
> *To:* OAuth WG ([email-masked])
> *Subject:* [OAUTH-WG] client authentication for implicit grant type
>
>
>
> 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 12 Apr 2011 08:50:56 -0700

It should include a section on phishing-like attacks.

EHL

From: Andrew Arnott [mailto:[email-masked]]
Sent: Tuesday, April 12, 2011 8:30 AM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] client authentication for implicit grant type

Thanks, Eran.  Will the security considerations section discuss this and recommend that auth servers warn the users of the potential phishing attack?

On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> 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.

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrew Arnott
Sent: Tuesday, April 12, 2011 7:28 AM
To: OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: [OAUTH-WG] client authentication for implicit grant type

client_id

Thanks for your time.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 12 Apr 2011 17:54:22 +0200

The proposed text already does 
(http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02).

When will you post the new revision of the core draft that includes the 
proposed text?

regards,
Torsten.

Am 12.04.2011 17:50, schrieb Eran Hammer-Lahav:
> *From:*Andrew Arnott [mailto:[email-masked]]
> *Sent:* Tuesday, April 12, 2011 8:30 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG ([email-masked])
> *Subject:* Re: [OAUTH-WG] client authentication for implicit grant type
>
> 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
>
> On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav 
> <[email-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] *On 
> Behalf Of *Andrew Arnott
> *To:* OAuth WG ([email-masked] <mailto:[email-masked]>)
> 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:
>
> 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
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 12 Apr 2011 09:28:47 -0700

Hopefully by the end of the week. My farm took all my free time this weekend.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Tuesday, April 12, 2011 8:54 AM
To: Eran Hammer-Lahav
Cc: Andrew Arnott; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] client authentication for implicit grant type

The proposed text already does (http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02).

When will you post the new revision of the core draft that includes the proposed text?

regards,
Torsten.

EHL

From: Andrew Arnott [mailto:[email-masked]]
Sent: Tuesday, April 12, 2011 8:30 AM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] client authentication for implicit grant type

EHL

client_id

Thanks for your time.

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Skylar Woodward <[email-masked]>
Date: Tue, 12 Apr 2011 15:25:02 -0700

Just as a response to Andrew, the concern is valid, and providers should be educated to warn users about the possibility of a forged identity.  This risk for forgery is actually possible for clients with and without secrets.   Anyone can spoof either type if the client ID is known, thus showing the approval dialog on the authorization endpoint.  The only difference is that the auth code returned will be useless to the phisher in the case of a client with a secret.

To this point, we always warn our users not to approve an app unless they trust the application that spawned the approval dialog.  We emphasize this warning even more when a client_id is presented which can't later validate the identity through use of a secret.

As a result of how hard it is to guarantee client identity in these cases, I think you'll find many providers downplay the identity in approval dialogs. The page title often reads something generic like "An application is requesting access to your account" followed then by details of the app.  We've refrained from displaying the name or icon too prominently in the top or title of the page for this reason.  Certainly, this is kind of guidance to providers is important for the security notes as well as the UI considerations.

So, while identity may seem hopeless in theory, it's actually useful as a context check, as Eran suggests.  (John's App? why is that asking for permission from this online pharma store?)  Moreover, its useful to providers in terms of tracking app usage because in practice, there is very little to be gained in forging an app's identity.  You might as well make your own convincing looking app name and icon.  Regardless the challenge remains for the providers to track abuse of the API and user data, be it from well-meaning apps, sneaky malicious apps, or mischievous apps masquerading as someone else.

skylar

On Apr 12, 2011, at 9:28 AM, Eran Hammer-Lahav wrote:

> On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav <[email-masked]> 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
>  
>  
> 	• 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.
> 	• 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.

---

From: Andrew Arnott <[email-masked]>
Date: Tue, 12 Apr 2011 19:45:30 -0700

Thanks, Skylar.  Eran's and your comments do alleviate my concerns somewhat.
 In reviewing the security considerations text, which I hadn't seen this
morning when writing my earlier email, I feel *much* better.  My favorite
part is this:

Authorization servers MUST NOT automatically process (without user
interaction) repeated authorizations without authenticating the
client.
By the way, a colleague at Microsoft pointed out that my email signature may
lead others on this list to believe I represent Microsoft in my
participation on this list.  I *do not represent Microsoft* in my
participation here.  I act as a lone developer.  I apologize for any
confusion.

On Tue, Apr 12, 2011 at 3:25 PM, Skylar Woodward <[email-masked]> wrote:

> Just as a response to Andrew, the concern is valid, and providers should be
> educated to warn users about the possibility of a forged identity.  This
> risk for forgery is actually possible for clients with and without secrets.
>   Anyone can spoof either type if the client ID is known, thus showing the
> approval dialog on the authorization endpoint.  The only difference is that
> the auth code returned will be useless to the phisher in the case of a
> client with a secret.
>
> To this point, we always warn our users not to approve an app unless they
> trust the application that spawned the approval dialog.  We emphasize this
> warning even more when a client_id is presented which can't later validate
> the identity through use of a secret.
>
> As a result of how hard it is to guarantee client identity in these cases,
> I think you'll find many providers downplay the identity in approval
> dialogs. The page title often reads something generic like "An application
> is requesting access to your account" followed then by details of the app.
>  We've refrained from displaying the name or icon too prominently in the top
> or title of the page for this reason.  Certainly, this is kind of guidance
> to providers is important for the security notes as well as the UI
> considerations.
>
> So, while identity may seem hopeless in theory, it's actually useful as a
> context check, as Eran suggests.  (John's App? why is that asking for
> permission from this online pharma store?)  Moreover, its useful to
> providers in terms of tracking app usage because in practice, there is very
> little to be gained in forging an app's identity.  You might as well make
> your own convincing looking app name and icon.  Regardless the challenge
> remains for the providers to track abuse of the API and user data, be it
> from well-meaning apps, sneaky malicious apps, or mischievous apps
> masquerading as someone else.
>
> skylar
>
>
> > The proposed text already does (
> http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02
> ).
> >
> > Now here me: I am not advocating for a client_secret in this case.  I
> >       • 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.
> >       • In scenario 2, which is far worse, an evil client can redirect
> the user to the authorization endpoint, requesting an implicit grant, and
> 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.

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 29 Apr 2011 15:03:00 -0700

On Tue, Apr 12, 2011 at 7:27 AM, Andrew Arnott <[email-masked]> wrote:
> 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:
>
> 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

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