Subject: [OAUTH-WG] OAuth2 security considerations for client_id

From: Karim <[email-masked]>
Date: Fri, 6 Jan 2012 12:06:05 +0100

Hello,

When using User-agent flow with OAuth2 for mobile platform, there is no way
for Authorization server to authenticate the client_id of the application.

So, anyone can impersonate my app by copying the client_id (and so get all
access tokens on my behalf), and this is applicable to Facebook,
Foursquare,...

This is not managed by OAuth2 ? Or I missed something ?

For Web applications (Web server flow), access token is stored on the
server side, and the client is authenticated using secret key.

-- 
Karim <[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 06 Jan 2012 14:21:45 +0100

Hi,

your observation is correct. OAuth security considerations recommend not to rely on secrets for authenticating mobile apps (aka native apps) but to manage them as so-called public clients. Please take a look onto section 10 of the core spec for further details.

regards,
Torsten.

Karim <[email-masked]> schrieb:

Hello,

When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application.

So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,...

For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key.

-- 
Karim

---

From: William Mills <[email-masked]>
Date: Fri, 6 Jan 2012 09:34:28 -0800 (PST)

Yeah, certainly for Mobile clients this is true.  There are classes of clients (server to server implementations notably) where clientID can be a proper secret and be usefule for client validation.

________________________________
 From: Torsten Lodderstedt <[email-masked]>
To: Karim <[email-masked]>; [email-masked] 
Sent: Friday, January 6, 2012 5:21 AM
Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id

Hi,

regards,
Torsten.

>For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key.
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Fri, 6 Jan 2012 12:44:21 -0500

The important thing to realize here is that just having the client_id 
doesn't get you access tokens, and it certainly doesn't give you access 
to all access tokens issued to that client_id in the past. It does allow 
for a phishing scenario in that it will let you try to impersonate a 
known-good client by copying the client_id, but each individual user 
will still have to authorize the fake client in order for it to get a 
new access token.

But keep in mind that this doesn't expose the user's actual credentials 
to the application (on mobile especially, assuming use of external 
browsers trusted by the platform -- as has been discussed on the list 
here, a bad application could always embed a browser and try to steal 
your credentials directly, but they can do that anyway without OAuth). 
The mitigation and cleanup of fake clients like this is also simpler, 
since you can revoke tokens without much cost to users and service 
providers.

These reasons are why it's suggested to use the authorization code flow 
with mobile apps, just without a client_secret. You can lessen the 
attack vector by using a trusted and preregistered callback_uri, and 
there's even been some discussion about how to do that with cloud 
services handling the callbacks for trusted applications on the platform.

  -- Justin

On 01/06/2012 12:34 PM, William Mills wrote:
> Yeah, certainly for Mobile clients this is true.  There are classes of 
> clients (server to server implementations notably) where clientID can 
> be a proper secret and be usefule for client validation.
>
> ------------------------------------------------------------------------
> *From:* Torsten Lodderstedt <[email-masked]>
> *To:* Karim <[email-masked]>; [email-masked]
> *Sent:* Friday, January 6, 2012 5:21 AM
> *Subject:* Re: [OAUTH-WG] OAuth2 security considerations for client_id
>
> Hi,
>
> your observation is correct. OAuth security considerations recommend 
> not to rely on secrets for authenticating mobile apps (aka native 
> apps) but to manage them as so-called public clients. Please take a 
> look onto section 10 of the core spec for further details.
>
> regards,
> Torsten.
>
>
>
>     When using User-agent flow with OAuth2 for mobile platform, there
>     is no way for Authorization server to authenticate the client_id
>     of the application.
>
>     So, anyone can impersonate my app by copying the client_id (and so
>     get all access tokens on my behalf), and this is applicable to
>     Facebook, Foursquare,...
>
>     For Web applications (Web server flow), access token is stored on
>     the server side, and the client is authenticated using secret key.
>
>     -- 
>     Karim
>
>
> [email-masked] <mailto:[email-masked]>

---

From: Paul Madsen <[email-masked]>
Date: Fri, 06 Jan 2012 12:48:22 -0500

William, presumably you meant 'client_secret'?

And is it fair to say that this reflects the current reality (of app 
distribution channels & OS protections) more so than any inherent mobile 
client limitation?

paul

---

From: William Mills <[email-masked]>
Date: Fri, 6 Jan 2012 10:24:28 -0800 (PST)

Yeah, I sure did.  Client ID being the moral equivalent of user agent string in a browser.

________________________________
 From: Paul Madsen <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Torsten Lodderstedt <[email-masked]>; Karim <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Friday, January 6, 2012 9:48 AM
Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id

And is it fair to say that this reflects the current reality (of app
    distribution channels & OS protections) more so than any
    inherent mobile client limitation?

paul

>your observation is correct. OAuth security considerations
              recommend not to rely on secrets for authenticating mobile
              apps (aka native apps) but to manage them as so-called
              public clients. Please take a look onto section 10 of the
              core spec for further details.
-- 
>>Karim
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: Karim <[email-masked]>
Date: Fri, 6 Jan 2012 19:48:50 +0100

The term "trusted client" is not applicable to mobile devices as they
cannot keep secret.
I agree that the "attacker" actions are limited even if he "discovered" the
client_id, actually he can do nothing as you pointed :
He needs approval from end user's to access their data, but how to alert
them (educate them) about the risks of phishing attacks....
We have no choice but to trust authorization servers to detect (this is
possible ?) any malicious use of client_id and to prevent end-user's each
time they are going to approve sharing data.

On 6 January 2012 18:44, Justin Richer <[email-masked]> wrote:

> doesn't get you access tokens, and it certainly doesn't give you access to
> all access tokens issued to that client_id in the past. It does allow for a
> phishing scenario in that it will let you try to impersonate a known-good
> client by copying the client_id, but each individual user will still have
> to authorize the fake client in order for it to get a new access token.
>
> But keep in mind that this doesn't expose the user's actual credentials to
> the application (on mobile especially, assuming use of external browsers
> trusted by the platform -- as has been discussed on the list here, a bad
> application could always embed a browser and try to steal your credentials
> directly, but they can do that anyway without OAuth). The mitigation and
> cleanup of fake clients like this is also simpler, since you can revoke
> tokens without much cost to users and service providers.
>
> with mobile apps, just without a client_secret. You can lessen the attack
> vector by using a trusted and preregistered callback_uri, and there's even
> been some discussion about how to do that with cloud services handling the
> callbacks for trusted applications on the platform.
>
>  -- Justin
>
>
> clients (server to server implementations notably) where clientID can be a
> proper secret and be usefule for client validation.
>
>   ------------------------------
> *From:* Torsten Lodderstedt <[email-masked]><[email-masked]>
> *To:* Karim <[email-masked]> <[email-masked]>;
> [email-masked]
> your observation is correct. OAuth security considerations recommend not
> to rely on secrets for authenticating mobile apps (aka native apps) but to
> manage them as so-called public clients. Please take a look onto section 10
> of the core spec for further details.
>
> regards,
> Torsten.
>
>
>
> Karim <[email-masked]> <[email-masked]>schrieb:
>
> Hello,
>
>  When using User-agent flow with OAuth2 for mobile platform, there is no
> way for Authorization server to authenticate the client_id of the
> application.
>
>  So, anyone can impersonate my app by copying the client_id (and so get
> all access tokens on my behalf), and this is applicable to Facebook,
> Foursquare,...
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>