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 protected]>
*To:* Karim <[email protected]>; [email protected]
*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 <[email protected]> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
