atebits

Fixing OAuth

February 18, 2009

Twitter is dancing around the idea of deprecating support for Basic Authentication, leaving only OAuth.

The current authentication process for Twitter clients is straightforward:

1. Launch a Twitter client
2. Enter your username and password
3. That’s it

If Basic Authentication goes away, and OAuth is the only option, the process would look like this:

1. Launch a Twitter client
2. Client does some magic, then quits and sends you to a special login page on twitter.com
3. You login on twitter.com
4. You “approve” the client that just sent you to the browser
5. Your browser quits, you get punted back to the client (where it then does some more magic to actually log you in)
6. That’s it

OAuth will make you – the user – jump through these hoops so you don’t have to type your password into the client application directly, for your own security.

Time to be frank: any security that OAuth claims – with respect to native applications – is an illusion. If a native app wants to get a copy of your password, it will get a copy of your password. If it wants to hijack the authentication process, bring up a bogus “browser” for you to enter a password into, register keyloggers, muck with your system web proxy settings and sniff passwords before they hit the wire, or phish you some other way, guess what: it can and it will. OAuth does not solve these problems. It just adds complexity to the login process.

But this post is not meant to bash OAuth – I think it’s a fantastic solution to authenticate other web apps. The problem is that it flat-out sucks for everything else.

So why is there a push to standardize on this single authentication system? Why shouldn’t Twitter implement OAuth and keep Basic Auth around? Well, I think they should, but I can imagine a number of reasons why they don’t want to: buzzword compliance, implementation simplicity, the ability to remotely disable access tokens from misbehaving clients (which is a legitimately nice feature).

I think Basic Auth is fine (over SSL at least). But OAuth is the juggernaut of this new age of web stuff, here I am, holding back the tide of buzzword bullshit and I know I’m going to lose. And to be honest, a few years from now when OAuth is finally integrated sensibly, I think it actually will be quite nice.

“Integrated sensibly” is key. Today is an opportunity to get it right.

Fixing OAuth

I have a tendency to think of things that have already been thought of, so I apologize if this has already been discussed and rejected. I also have a tendency not to think things entirely through, though I’m hoping this post is a starting point, not a complete solution. In any event, I think there may be a way to fix OAuth and you’d only have to change 4 words of the spec.

The OAuth Core 1.0 spec hard codes the concept of a web browser as the means to authenticate with a provider. I would like to generalize that and introduce a new term, call it an authentication gateway for now.

An “authentication gateway” is any program that is capable of communicating securely between a device that is currently running a consumer and a service provider. A web browser is a perfectly acceptable type of authentication gateway. The idea is to allow for a few new types.

I think the ultimate goal is to have a single, global, native-looking, “blessed” authentication gateway on every device. This gateway could be expressed on different devices in different ways. On the iPhone for example, it could be represented as a special OS-provided window (running in a protected process) that slid up over an app, allowing the user to enter a password (or authenticate via something else like OpenID). The sheet would then slide back down revealing the app after authentication was complete. The requesting app would never need to quit. There would be no need for any web pages, and the authentication experience would be completely standardized across every app on that device that used OAuth.

On the Mac, the authentication gateway could be expressed much like the current keychain dialog today.

One added bonus of implementing OS-level “blessed” authentication gateways is that the OS vendor can use every trick in the book to prevent phishing. They can use secret APIs to make sure key strokes aren’t logged and proxy settings haven’t been compromised. They can also implement a system allowing users to validate the authenticity of the authentication gateway itself. For example, it would be trivial for a malicious application to bring up a window that looks and works exactly like the OS-provided gateway, but stole the user’s password. An OS vendor could prevent this by doing a “choose a special image when setting up your device, and check to make sure the image matches when you see an authentication window come up” (or ideally a something a little less cheesy). A number of financial sites use this trick. The benefit is that each provider wouldn’t have to come up with their own implementation of it (forcing the user to remember a different image on each site). The user would only have to remember one image, to check validity of their single, system gateway.

The other added bonus is that there is no reason why authentication gateways need to be limited to GUIs. A command-line gateway would be possible. So would some other gateway for an interface (or a device that doesn’t have an interface) that nobody has even thought of yet.

Chicken / Egg

There’s a bit of a problem here, and that is how to do this seamlessly and securely without explicit support from OS vendors. In a nutshell, we can’t. What we can do is build it, prove it works, then beg for support.

We can build this today. It won’t be perfectly secure, but it will be at least as secure as Basic Auth (in the sense that clients would still be able to see user passwords). That’s good enough for me, and that’s good enough for everyone who uses an email client today. It would be easy enough require other web apps to use the “web browser”-type authentication gateway, so security would stay exactly the same in that regard.

The only reasonable way to accomplish this today is to have each native app carry along their own implementation of an authentication gateway. On something like the iPhone, it would be unreasonable to require users to download a separate “authentication gateway” app to authenticate something else. On the desktop, you could certainly have apps that could install some shared gateway, but that could be easily abused by malicious apps, so it’s probably better for now for each app to carry their own.

There’s nothing stopping apps from sharing code, I’d be happy to contribute to an open source implementation of something like this. Again, this post was simply an attempt to get some discussion going. If you have your own thoughts, I encourage you to join in the discussion here and contribute to the OAuth Desktop Discussion Wiki.

Let’s get this right.