Dropbox recently announced their API, which is pretty exciting because it's a great service. It uses OAuth for authentication, but under the Authentication For Mobile Devices section, there is this statement:
While Dropbox uses OAuth for the base of its authentication strategy, OAuth doesn’t work very well for mobile devices. It’s much too difficult and error prone to have a mobile device switch context to a browser, do the OAuth handshake, and then magically return to the original application with the tokens in hand ready to use. It’s bad for user experience and it’s bad for developer sanity.I emphatically disagree with this statement, at least as far as Android is concerned. I think OAuth vastly improves the user experience, even from a mobile app and this attitude that it's too hard or too much trouble is damaging to both the experience and security of users.
Lets take their statement piece by piece.
It’s much too difficult and error prone to have a mobile device switch context to a browserThis is trivial on Android. I'll use the Gowalla OAuth flow in my examples because I think it's an elegantly simple implementation of OAuth, but this works for any OAuth system:
That's it. The browser is launched and the user will see the Gowalla authorization page. If they're already logged in, they don't even have to type their username and password. Now there is an activity that is difficult and error prone. I hate entering login credentials on my phone, and I can copy and paste them from LastPass. Even with Swype, typing on a mobile device is neither easy or error free. Save your users the headache and use OAuth.
It’s much too difficult and error prone to ... do the OAuth handshake, and then magically return to the original application with the tokens in hand ready to use.
Again, this "magic" is almost trivial for an Android app. You simply specify that your activity can handle the custom data URI scheme you specified in your redirect link:
Once the user clicks "Allow", your activity will be launched and the Intent data will have a parameter telling you the access code needed to complete the OAuth handshake. This isn't any more difficult and error prone than implementing OAuth in a web application. But it's not that difficult, because there are plenty of great OAuth libraries out there to help you on the web server, and you can use them on your Android device too.
It’s bad for user experienceIf this is true for OAuth on mobile devices, then it's even more true for the web and we should abandon OAuth completely. An app launching a browser is not an unfamiliar thing. Receive an email with a link on a desktop, you click the link and it opens your browser. This is normal, good UX. I click a link to comment on your site and you take me to Facebook? That's weird. As a user I'm not sure what is going on. Suddenly everything looks different... I thought I was commenting on your blog? Why are you on my Facebook?
The response to this (for web applications) is that users simply need to become familiar with the concept and then it wont seem weird at all, it will seem normal. That argument also works for mobile devices. In fact, if you are worried about the user not knowing what is going on, just tell them! "You will now be taken to Gowalla to authorize this app. You may be asked to log in. After you authorize myApp, you will be returned here."
OAuth is Good for Dev, and Good for UXThe idea that OAuth isn't suited for mobile isn't in any way grounded in the Android mobile experience, as far as I can tell. That might explain why Dropbox has a lot to say about it's Objective-C library, but for Java they only offer two words: "Coming soon."
Anything you can truthfully say about OAuth being bad UX or bad for dev in regards to mobile is equally if not more true for the web. But nobody is suggesting that OAuth be abandoned on the web and we go back to asking users for their passwords. So don't do it in your mobile apps either.