OAuth: Not a Silver Bullet

OAuth[1] provides a standard protocol for delegated authentication. That is, it lets a site like Twitterank[2] get controlled access to your twitter account without your having to give Twitterank your username and password. Instead, there's a multi-step authentication process involving a "token" that grants temporary, limited access to a third party service.

This sort of authentication system has been in use for many years in commercial and academic systems. OAuth just brings a cut-down version to the web 2.0 world.

You may ask yourself: If it's so great and it's been around forever, why doesn't everybody use it? The short answer is that it's a major pain in the rear-end both for developers and users, and most of the time it's just not worth the bother.

As a developer I actually like OAuth. I think it's wonderful for the times when the added complexity of delegated authentication makes sense. But the complexity is not without cost. For trivial, single-purpose services it is, at best, a very small win, and possibly even a net loss.

Ignoring the implementation difficulties for now, let's take a quick look at the user experience via Twitter and the (hypothetical) Twitterevil service. Twitterevil operates by promising to calculate an amusing ranking number for your tweet history. It does in fact do that, but it also keeps your username and password and uses them to posts spam tweets. We'll look at scenarios both with and without OAuth.

The first scenario, sans-OAuth, goes someething like this:

1. I surf to twitterevil.com and enter my Twitter username and password.
2. Twitterevil logs into Twitter as me, grabs some data, and uses it to calculate some statistics, which it tweets under my name. It also (contrary to what it says on the Twitterevil home page) keeps my username and password.
3. Later, Twitterevil starts using my Twitter account to post spam links.
4. I notice the spam links and use Twitter's password recovery feature to change my password.
5. Twitterevil can no longer use my account.

The OAuth scenario goes like this:

1. I surf to Twitterevil. Twitterevil has a login button button that redirects me to a special Twitter OAuth login page.
2. I enter my username and password on the Twitter OAuth login page, and hit the "OK, allow Twitterevil access" button.
3. I get redirected back to Twitterevil, which calculates my score, tweets it, and then starts posting spam links.
4. I notice the spam links, log into my twitter account, go to my OAuth delegated permissions page, find the twitterevil.com entry, and remove Twitterevil's permissions.
5. Twitterevil can no longer use my account.

So, conservatively, the OAuth scenario has more steps and involves the new concept of "delegated authentication". This concept existed implicitly before but is now (very) visible to the user in the form of a multi-step login process and a new "OAuth delegated credentials" page. All to get the same end result.

Actually, as some of you may have noticed, I've lied by omission. There's an alternate OAuth scenario that I'm leaving out. It's a change to step 2, and it goes like this:

1. ...
2. I enter my username and password on the Twitter OAuth login page, and then read through a paragraph of explanatory text about just what Twitterevil is asking permission to do: "twitterevil.com is asking permission to [Read through your posting history] and [Post tweets on your behalf]. Do you want to give twitterevil.com permission to do this (a) Once (b) For the next little while, or (c) Permanently. Note that you can always go back and revoke permission later."
   

No, I'm not kidding.

Anybody who's looked at the problem of user security knows that nobody, even security experts, ever reads that crap. They just hit the default button automatically. So 2b is "cover your behind" security theater, it provides no real security in the vast majority of cases.

Flickr, which uses a pre-oauth delegated authentication scheme, does it like 2a. They don't expose out the permissions set during authentication, instead allowing the user to go in later and see just what they approved (if users ever cared to look, which they don't). I suspect this is the result of some user experience testing. It's certainly easier.

A service like Twitter has a very limited number of possible actions, so the model presented in 2b is unusually simple. A more complex application could have dozens of possible permissions. Developers who care about the experience will probably layer a "user level" set of permissions on top of the real underlying implementation permissions, but most won't. And that's just nasty.

So, depending on how exactly the service implements the OAuth user experience, the number of user actions is either slightly or significantly more complicated for the OAuth scenario. The conceptual complexity (how many different ideas the user must keep in mind) is a clear loss for OAuth, especially if the service exposes out it's internal security architecture in the OAuth security screen.

But.

I was just asked by a service I won't name to hand over my Google username and password so that it could access my Google Reader data[3]. And I said "no", because my Google account is not trivial or simple and there are real consequences to handing it over to somebody I don't fully trust.

OAuth is a sledgehammer, and it does not make sense to use a sledgehammer when you can get away with something less. Developers should use their very limited time and money to go simplify their design, not add in significant new complexity where it's not needed.[4]

But if, after serious reflection, you decided you do need a sledgehammer, OAuth appears to be shaping up into a good choice.

[1] http://oauth.net and also http://en.wikipedia.org/wiki/OAuth (please help with the lame Wikipedia entry) I've always assumed it stood for Open Authentication, but I don't see that written down anywhere.

[2] Twitterank is a fun example because Brian Oberkirch tweeted, as a joke with a point, that he set it up as an evil password collector. But it got picked up by and republished as a non-joke by ZDNet. I love ZDNet's lame attempt to substitute boilerplate "rumor has it" for fact checking.

[3] Google is actually moving towards OAuth for all its services, but Reader doesn't have an "official" API yet, and OAuth doesn't work. Developers must use a sort of backdoor ClientLogin hack.

[4] Note to complainers: There is some accidental complexity in OAuth that can be overcome via better libraries and documentation, but the base problem is the inherent complexity of exposing a more complex authentication scheme, and that exposure is at the heart of the claimed benefit of OAuth.