(Or, The Challenges of Using OAuth in Desktop or iPhone Applications)
Services adopting or considering OAuth like Twitter, face the question of how to get developers to move from their HTTP Basic Auth API to their OAuth API. If you keep both, why would anyone bother to learn a much more complex authentication method and subject their users to a workflow where at least some will drop off. And let’s not forget that services can always ignore the API and use screen scraping like in the “good old days” if you make it too hard.
Dumping the problem on your API developers (or worse, your users) isn’t going to help anyone.
OAuth is great for web applications, that is, applications living on the web. You go to one site, ask to do something with data from another site, jump over there, say it is ok, come back, success. With just a tiny bit of good web design, server-to-server OAuth flow can be easy and pleasant to use. But for installed applications such as those running on desktops or iPhones, the OAuth Core 1.0 spec does not provide a usable pattern, at least no out of the box.
Making a desktop application open a browser (embedding one is really bad security practice) with the hope that the user will know what to do (and that the window will not get lost under other windows or browser tabs), and then somehow find its way back to the application is not an acceptable solution.
The real challenge in OAuth usability is educating users why the redirection flow is better for them (because it is not easier or faster). If they understood why giving their passwords to someone else is bad, they would have the tools to make smart decisions. The problem of course is that most people either don’t care or don’t know. But removing a perfectly valid authentication option such as HTTP Basic Auth from the tools available to developers is not the right way to protect users.
So You Decided to Add OAuth for Your Site
Here are some rules about how to better implement, manage, and communicate your new API to your developers and users:
Rule #1: Don’t promise something you cannot deliver
In addition to the usability issue, not all the functionality offered by OAuth is available to non web-based consumers. The Consumer Key mechanism – the credentials used to authenticate the application (as opposed to the end user) – cannot be used when the software is available for inspection on the client side.
If the secret is available locally, someone can get it out no matter how hard you try to hide it (and hiding it is really not part of an application developer’s responsibility). This includes scripts running on the client side, installed applications, iPhone applications, or anything that is not executed on a well protected web server.
Consumer Keys are useless unless you know who you gave it to, how they are going to use it, and that you can trust them to keep it secret. Only secrets stored on servers have a chance of staying secret, and even then, only trustworthy companies can really be trusted not to leak those secrets out. Service Providers should not promote the value of OAuth by talking about the value of the Consumer credentials.
So forget about using the Consumer credentials for anything other than somewhat reliable statistics. If I was going to abuse Twitter’s API, I would not apply for my own application key. I would steal one from a well known and well deployed application so that if Twitter tried to shut me down using the key, they would lose all the other legitimate users using the application I stole it from.
Rule #2: Life isn’t black and white
OAuth will be more successful if used in conjunction with other existing authentication methods. There is nothing wrong with using HTTP Basic Auth to get an Access Token, and then using OAuth to access the resources. Use each method for what it was designed for. When users installs a desktop application on their local computer, they are already taking a huge risk. The additional risk of giving that application their username and password is insignificant in comparison.
Most sites use a combination of HTTP Basic Auth, HTTP Digest Auth, some form of Cookie auth, strong certificates auth, and hopefully OAuth. In other words, their own auth soup. This isn’t necessarily bad if done correctly. But to pretend that OAuth can replace all the other methods is plain silly.
Your site’s security is determined by its weakest point. If you allow your users to log into the site using HTTP Basic Auth, developers can build applications taking advantage of that. Does that mean you will make normal web login super complex and secure? Not likely. So let’s not pretend that keeping an HTTP Basic Auth API alive is any bigger threat.
So how do you get developers to switch over to your preferred method for API access?
Rule #3: Carrots work better than sticks
Show your users and developers the value in OAuth. Don’t scare them into using something that is just not as good as the less secure solution they had before (or will continue to have). After all, who do you think you are, telling me (the end user) how I should protect my own credentials? It is my right to choose comfort over security, and most people will knowingly choose that.
At this point, the biggest value OAuth offers to developers is removing the need for them to store users’ passwords. Of course, this really only helps web-based sites because desktop ones only need to store a single password. By itself, OAuth doesn’t offer application developers much. This isn’t good news. Only few service providers, with Fire Eagle being the gold standard in this category, offer users and developers real added value that can only be done using OAuth. Key word here is ‘using’.
How can you offer more value? Fire Eagle is a location data warehouse. Since location is a very (very) sensitive and private matter, giving your username and password to applications will give them unlimited access to where you are (or change your location). This isn’t good and will freak out most people (even those who don’t care about password security). What OAuth gives Fire Eagle users is the ability to control exactly how their location information will be shared (including accuracy and duration). Without that, users will not trust applications, and that is bad news for application developers.
In addition, Fire Eagle gives developers tools to perform batch activities which are not possible using HTTP Basic Auth, as there is nothing to tie all those credentials into a single transaction. It makes Fire Eagle uniquely efficient, something almost every web application today can learn from. And they use OAuth as their framework to accomplish that. It is brilliant in its simplicity. If you are implementing OAuth for your site and have not studied the Fire Eagle implementation, drop everything, and go do it right now.
For the end user, the biggest value OAuth offers beside the “not spreading your password around” is the ability to turn off one application when something goes wrong (without breaking everything else). Make the access control panel for your service an attractive and usable feature. Show users how much control they really have when they use OAuth-enabled applications. Once they get used to it, they will find it hard to give up that control.
To Basic Auth, or not to Basic Auth
So should Twitter discontinue their HTTP Basic Auth API? No.
But they can still make some changes that will keep their community happy and still cost them less and offer better security. One reason why they should not keep both is cost. Supporting two APIs will obviously cost them more resources. But there are ways to keep HTTP Basic Auth access without any significant duplication. For example, they can offer a single HTTP Basic Auth endpoint that generates authorized Access Tokens, and keep the rest of the API OAuth-only.
None of this means that OAuth isn’t great for desktop applications or mobile devices. It just means that it doesn’t offer a complete “prepackaged
” solution at this point. But with a little bit of creativity, understanding the unique threat model of each application, and user education, OAuth can work extremely well.