web page hit counter

Sunday, November 23, 2008

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.


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.

You should follow me on twitter here.


Blogger Daniel said...

1. "security theater" is great & should be used more often

2. I want to know the service that wanted your Goog Reader user/paser

5:20 PM  
Blogger Blaine said...

To some extent, you're right. However, I think your scenarios mis-represent the issues at stake. In the first scenario, where the attacker steals the password, the worst case is much, much worse.

Most users re-use passwords at many sites. It dumb, it sucks, but it's the reality, and it's not going to change anytime soon. With that in mind, the stolen Twitter password is now a stolen GMail password. An attacker could log into GMail for *years* without anyone knowing differently, and in the meantime steal a plethora of personal details, logins, etc., in such a way that the user could never just reset their password.

Moreover, I'd argue that to the average user, passwordless delegated authentication is easier than delegated authentication with a password, since it's really just clicking a button instead of typing in a username and password that don't make sense in a foreign context.

An example: I'm at Moo.com, and they ask me to type in my Flickr username and password — my flickr username is "bob", but my login is "joebob27@yahoo.com", and, wait, I don't have a password for moo.com. WTF?? So I either give up, or end up trying every username / password combination I can think of (thus giving up every credential I have, instead of just one). These are experiences I've seen real people have. Hell, I helped start OAuth and have been very active in the community, and I've done very similar things.

With OAuth, it's much simpler for users; "Yes, I want to give Moo.com permission to see my photos." There's no need to have complicated language around the permission granting step. If the site has complicated language there, then it's a good bet that the rest of the site has complicated language, too.

6:38 AM  
Anonymous Caleb Jenkins said...

Christopher -

First, great post! It's easy to see something like OAuth on the horizon and want to run with it just because it's the new hotness.

One thing missing from scenario 1 is ... evil twitter site keeps your username and password, changes your pw, and locks you out of your own account. OAuth would prevent that from happening.

That, and the fact that so many people do use the same password in many places (mentioned above) are the main reasons that I'm looking forward to a day when frameworks, libraries and tooling will make implementing OAuth and OpenID dirt easy... one day. :)

8:19 AM  
Blogger Diogo said...

I agree with your post. Im developing a small extranet app for the company I work for.

My boss, unfortunately, loves Yammer (closed twitter-like app for enterprises). So he asked for an integration with Yammer. Yammer has a (somewhat) REST API, so I though it would be pretty easy.

I was wrong. yammer decided to use OAuth, completely disabling basic auth. IT DOES NOT MAKES ANY SENSE, at least in your case: the extranet is ours, is hosted on our server, we (the people who work here) se we can trust it 100%. We dont have to worry about OUR app making bad use OUR yammer accounts. So, we dont need OAuth, we dont want OAuth, but we are stuck with it.

So, instead of spending 30 minutes to get the yammer integration working, is been 2 days already, specially since their OAuth scheme is badly documented (with actual errors) and because they decided to add another step to it (has explained on this almost-hidden addendum: https://www.yammer.com/api_oauth_security_addendum.html), that is preventing me from using any know OAuth library to make the job easier for me.

So, hooray! Here I am wasting my time and my company money because Yammer decided we needed more security then we actually need. But OAuth is cool, all the cool kids are doing it, so lets do it!

9:13 AM  

Post a Comment

<< Home