OMFGAuth

TL;DR: Stop thinking of OAuth as the only way to secure APIs. Its not as widely adopted, nor as standardized, as you think. Do what’s best for your needs and your scenario, and quit worrying about OAuth compliance.

In my “Painless OAuth” talk yesterday at Web 2.0 Expo, I declared my opinion that it’s time to step back from the OAuth specification and consider if it’s really what’s needed for delegated authentication.

That’s right. I said it’s time to sunset OAuth.

While I was at Mashery, I argued for OAuth support within the Mashery service. Mashery still offers, and will likely continue to offer, an OAuth Accelerator option to its managment services. I got on the bandwagon in late 2007, and Mashery’s first OAuth-assisted customer went into production in mid-2008.

The promise of a simple, standard way to provide secure delegated access is fantastic. It’s universally felt that Digest Authentication doesn’t meet all the necessary use cases, and is overly complex. OAuth sought to be more accessible.

In my estimation, the OAuth mission has failed. We’re roughly four years into it, and there’s a tremendous amount of confusion among developers about what version of OAuth to use, who’s using what version, what libraries support what API providers, who’s running OAuth or simply something OAuth-like … and that doesn’t even get into debugging the often-difficult implementation challenges.

Today there are many OAuth-like services, such as Twitter’s xauth and OAuth Echo authorization paths, which I think of as “OAuth adjascent.” Then you’ve got Facebook’s nearly-OAuth 2.0 implementation, which makes up its own rules for the Desktop App flow.

There are certainly examples of strict OAuth spec adherance out there, but if the two largest organizations using OAuth or OAuth-adjascent approaches have chosen to deviate from the OAuth standard, are those specs really getting the job done? Nearly every conversation I have these days with developers or providers about OAuth includes a lot of eye-rolling, cursing, and assorted other expressions of frustration, including mentions of flavors, dialects and variants of OAuth. In other words, there is no standard in the real world.

One thing that’s important to consider is the set of problems OAuth set out to solve. (Eran & Chris, if you’re reading, let me know if I’m leaving something out.)

• SSL is too expensive. (From computational and financial perspectives.)
• HTTP Basic is too simple and insecure, and HTTP Digest is too complex.
• It would be great to standardize the kinds of authorization delegation that Flickr allowed. (Everyone wanted a way for users to grant permissions to applications or APIs without having to share their actual usernames/passwords with untrusted parties.) This has come to be known colloquially as the Three-Legged Scenario.

… and back in 2007, that was more or less it. The big deal around standardization was that developers wanting to integrate with services like Flickr or others had to spend a lot of time learning the details of a particular service’s custom security requirements and write new code to handle the same kinds of problems. So, code reuse through libraries has been a desired benefit of the standardization goal.

Now, in the post-FireSheep era, SSL is no longer considered to be that expensive, cost-wise or computation-wise (it’s not even considered “optional” anymore for a lot of things). SSL has gotten less expensive, and computing resources have become truly elastic. (Remember: in early 2007, Amazon EC2 still only offered one size of instance — what is today known as “small”).

We also have no reliable standard, so OAuth libraries are fragemented. Does your library support xauth? Or OAuth WRAP? Or OAuth 2.0? Ok, which draft of OAuth 2.0? … and so on.

Something we’ve seen at Mashery is that successful API programs are providing client libraries themselves. So, the situation that was common in 2007 — “raw” APIs which required everyone interested in using them to write their own code — has largely evaporated. The API providers that are continually referred to as “the guys to emulate” not only provide officially-supported libraries in multiple popular programming languages, they also nurture and support community-contributed code development. See https://simplegeo.com/tools/ for an example of how this is done.

Finally, I submit that OAuth 2.0 in its entirety is considerably more complex than HTTP Digest.

The world in which OAuth seemed like an absolute necessity no longer exists. Plus, the current state of affairs in the OAuth community says, as Dave Winer said a bit over a year ago “Wait — they’re ripping up the pavement. Don’t deploy.”

Does this mean I think standards are bad? No. Standards are obviously what make this big crazy thing called the Internet work. Without them, we’d be nowhere. However, I DO think that not everything needs a standard.

Can delegated authentication happen without the OAuth standard? Of course it can. There doesn’t need to be a standard — this whole thing could be done with a set of well-vetted Best Practices recommendations. Let API providers build and support libraries for their services, and let the Big Thinkers (who spend so much time thinking I find it hard to believe they’re actually doing any practical building) behind OAuth write up and argue about those Best Practices. See OWASP and SANS for how this has been done.

The path we’re on with OAuth today feels an awful lot like SOAP to me. (WS-* and all that.) Do we as developers and implementers really want to go there?

We’ve all built a couple prototypes for things that we threw away. That doesn’t mean that it was all a wasted effort, or that there’s nothing valuable that can be extracted from those early runs at the problem. I’d love to see what’s been learned from the OAuth experiment distilled into a set of best practices that others can pick from as it suits them.

And finally, I’m well aware that OAuth will be around for a long time. It certainly won’t die off as quickly as OpenID did, simply because it’s gotten better traction. (UPDATE: @joestump pointed out that OpenID isn’t dying as quickly as some think, and that the tech is still widely used. Tweets about this.)

If nothing else, those who are on the fence about implementing OAuth should take comfort in that position. You’re not alone. If Twitter, Amazon, Flickr, and Facebook aren’t using OAuth as specified, should you? It’s okay to consider a different approach than OAuth. Lots of providers do. In fact, one large Mashery customer that’s been using OAuth 1.0 for a long time is not going to use OAuth 1.0 or OAuth 2.0 in the next version of their API. They’re going to use an approach they’re building in-house that suits their set of needs the best, and is easier for developers to implement and understand.

Make no mistake: security is hard. However, it’s not so hard that your only option is to be spoon-fed by the OAuth Working Group. Think for yourself, and more importantly, for your use-case. Then do what’s best for you and your organization.

Here are the slides from my talk, if you’re interested. Especially nice if viewed with Safari, as you get the transitions and stuff. Also, Brooks Grigson took some great notes that might help those looking at the slides.