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

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 <torsten@lodderstedt.net>
> *To:* Karim <medkarim.esskalli@gmail.com>; oauth@ietf.org
> *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.
>
>
>
> Karim <medkarim.esskalli@gmail.com> 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,...
>
>     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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth