Hey folks, I'm the product manager for the API and integrations at FreshBooks. Decided to pop my head in here because we're facing this issue right now.
On Aug 19, 12:23 pm, Brian Eaton <bea...@google.com> wrote: > On Wed, Aug 19, 2009 at 4:01 AM, Carl H.<charr...@gmail.com> wrote: > > I am currently working on an OAuth provider for Android. As such any > > application could use the OAuth application across the device > > ecosystem. The idea would be that the OAuth application has already > > been authorized to a majority of OAuth enabled sites and let other > > application use that information for sending request to those sites. > > As such it would be useful to have an API key per device instead of > > per application. So each device (mobile user) would have its own key > > which could be used by several application. > > This is how we're approaching the > problem:http://code.google.com/apis/accounts/docs/OAuthForInstalledApps.html. I have three answers to this problem 1. Request tokens are not bound to physical objects It's insufficient to provide a key for each device, since the key can be cloned by an attacker and used on another device. e.g. if you gave Alice the consumer key AlicesPhone for her mobile, she could give her key to Bob and he can use it on his mobile and pretend to be Alice. 2. Unverified consumers We're doing planning to do something similar to Google's anonymous/ anonymous. However. we are using a pre-negotiated consumer key (e.g. FreshBooksForAndroid) and a *blank* consumer secret, as per the spec, Section 4: "The Consumer Secret MAY be an empty string (for example when no Consumer verification is needed, or when verification is achieved through other means such as RSA)." Then we'll throw up a dayglo orange warning message to the end user. The reason we want a specific consumer key is so we can produce metrics and reports for the application developers. 3. Out-of-band negotiated white lists I had an idea to reduce the danger of unverified consumer keys for mobile phones, as there is a particularly excellent way of identifying the device: the mobile phone number. You can maintain a white list of mobile phone numbers on the service provider. For instance, in FreshBooks, end user would authorize only (416) 555-1212, (212) 555-1212, and (415) 555-1212 to grant access to FreshBooksForAndroid. The Android app would then pass along the mobile phone number in the request token request. If that number does not match the white list, the request is denied. While this does not eliminate spoofing of the Android app, it does prevent attackers from abusing the unverified consumer key to generate tons of request token requests. We intend to rate limit consumers from making too many requests for security reasons, and so that opens us up to spoofing denial-of-service attacks. We toyed with the idea of using the mobile phone number as the consumer secret, but that is wrong, I think. It's better to pass it as a query parameters. Depending on how tight you need to be, you can also go a step further and use SMS to ensure the mobile phone number is in fact owned by the end user. Note that will not prove they own the user account on the service provider. You will still need to provide an authentication challenge as with web-based OAuth requests. And please don't request their password over SMS! Cheers, Sunir Shah, Chief Handshaker, FreshBooks (416) 481-6946 x224 http://www.freshbooks.com/team/sunir http://twitter.com/sunir P.S. We are not developing an Android app, though I'm happy to talk to anyone who is interested in doing that for us! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
