I realize that this doesn't work generically, but at Facebook we only plan to offer the username/password flow to a small number of partners. We figure that we'll work out device/app authentication on a case by case basis depending on what is possible. We've also thought about issuing clients a separate secret which only works on this flow and couldn't be repurposed for other flows if it were to be stolen.
I believe Google is going to solve this problem by not supporting the username/password flow in the first place. --David On Wed, Apr 28, 2010 at 9:01 PM, Tosh Meston <[email protected]> wrote: > Hey David, > Thanks for the response and clarification. Agreed. The mobile device > shouldn't keep the client secret so passing in the body in an SSL request is > out, and signing the /access_token request is out for the same reason. So, > it doesn't seem like there is a way to ensure that value in the > oauth_client_identifier really represents that client, if I understand > correctly. Is that an issue? > > Evil client X could get an access_token and token_secret for another app, > but would only be able to make successful calls to protected resources if > the platform failed to check if the app represented by the > oauth_client_identifier is the same app represented by the > oauth_consumer_key, and also used the oauth_client_identifier as the > application id. > > Just thinking aloud and trying to get my brain around this... > > Thanks! > Tosh > > > > On Wed, Apr 28, 2010 at 2:19 PM, David Recordon <[email protected]>wrote: > >> Hey Tosh, >> I think this example just needs updating. In most cases the username and >> password flow will be used on applications or devices which can't keep >> secrets. Thus specing that the oauth client secret is used is a poor idea >> from a security perspective. I imagine that different devices will be able >> to keep secrets in different manners and that this will be used in a more >> case by case basis. >> >> --David >> >> >> On Wed, Apr 28, 2010 at 4:26 PM, Tosh Meston <[email protected]>wrote: >> >>> Hi everyone, >>> I see that in draft specification, under the username and password flow, >>> the oauth_client_secret is not listed in the required or optional request >>> parameters, but is included in the example request. Is it correct to assume >>> it should be listed it in the required parameters? >>> >>> POST /access_token HTTP/1.1 Host: >>> server.example.comoauth_client_identifier=s6BhdRkqt3&oauth_client_secret=8eSEIpnqmM&oauth_username=daveman692&oauth_password=1password >>> >>> >>> http://www.ietf.org/mail-archive/web/oauth/current/msg01396.html#anchor9 >>> >>> Thanks, >>> Tosh >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
