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 <jric...@mitre.org> wrote: > 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 <tors...@lodderstedt.net><tors...@lodderstedt.net> > *To:* Karim <medkarim.esska...@gmail.com> <medkarim.esska...@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.esska...@gmail.com> <medkarim.esska...@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 > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Karim <medkarim.esska...@it-sudparis.eu>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
