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
