> Kris - Can you clarify why phones can't protect the client secret? This > sounds like it would be a major issue for a lot of people.
Mobile apps on phones like iPhone are installed apps, and it is not possible as far as I know to prevent the client secret from being extracted – you have to rely on the user to know if the app they installed is reputable. Static string constants can be easily extracted, but even if you tried to obfuscate the secret in the compiled code, one could extract the key out with a jail-broken phone using a debugger to capture the secret when it is passed to the API or installing a root certificate to establish a man in the middle to sniff the client secret when it is sent using https. And if you think you can use push notifications to send your app a new client secret, push notifications have been hacked too. On an installed app, the client id is more of a user agent string, you can use it to try to clue the user into a mismatch between the app they downloaded and the app the website thinks they've downloaded when they are asked to approve. With the password grant type, it is totally up to the user to know if they can trust the app. By allowing that grant type in an installed app, you open up the grant type to an unsavory app with a little determination and it would be up to the user to know better not to give their credentials. For more perspective, please read the following articles (as it relates to mobile apps, client secret, and the password grant type): http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/ http://benlog.com/articles/2010/09/02/an-unwarranted-bashing-of-twitters-oauth/ http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
