Monthly Archives: July 2012

Why I Still Like OAuth

That sound of a door slamming last week was Eran Hammer storming out of the OAuth standardization process, declaring once and for all that the technology was dead, and that he would no longer be a part of it. Tantrums and controversy make great social media copy, so it didn’t take long before everyone seemed to be talking about this one. In some quarters, you’d hardly know the London Olympics had begun.

So what are we to really make of all this? Is OAuth dead, or at least on the road to Hell as Eran now famously put it? Certainly my inbox is full of emails from people asking me if they should stop building their security architecture around such a tainted specification.

I think Tim Bray, who has vast experience with the relative ups and downs of technology standardization, offered the best answer in his own blog:

It’s done. Stick a fork in it. Ship the RFCs.

Which is to say sometimes you just have to declare a reasonable victory and deal with the consequences later. OAuth isn’t perfect, nor is it easy; but it’s needed, and it’s needed now, so let’s all forget the personality politics and just get it done. And hopefully right across the street from me here in Vancouver, where the IETF is holding it’s meetings all this week, this is what will happen.

In the end, OAuth is something we all need, and this is why this specification remains important. The genius of OAuth is that it empowers people to perform delegated authorization on their own, without the involvement of a cabal of security admins. And this is something that is really quite profound.

In the past we’ve been shackled by the centralization of control around identity and entitlements (a fancy term which really just describes the set of actions your identity is allowed, such as writing to a particular file system). This has led to a status quo in nearly every organization that is maintained first because it is hard to do otherwise, but also because this equals power, which is something that is rarely surrender without a fight.

The problem is that centralized identity admin can never effectively scale, at least from an administrative perspective. With OAuth, we can finally scale authentication and authorization by leveraging the user population itself, and this is the one thing that stands a chance to shatter the monopoly on central Identity and Access Management (IAM). OAuth undermined the castle, and the real noise we are hearing isn’t infighting on the spec but the enterprise walls falling down.

Here is the important insight of OAuth 2.0: delegated authorization also solves that basic security sessioning problem of all apps running over stateless protocols like HTTP. Think about this for a minute. The basic web architecture provides for complete authentication on every transaction. This is dumb, so we have come up with all sorts of security context tracking mechanisms, using cookies, proprietary tokens, etc. The problem with many of these is that they don’t constrain entitlements at all; a cookie is as good as a password, because really it just linearly maps back to an original act of authentication.

OAuth formalizes this process but adds in the idea of constraint with informed user consent. And this, ladies and gentlemen, is why OAuth matters. In OAuth you exchange a password (or other primary security token) for a time-bound access token with a limited set of capabilities to which you have explicitly agreed. In other words, the token expires fast and is good for one thing only. So you can pass it off to something else (like Twitter) and reduce your risk profile, or—and this is the key insight of OAuth 2.0—you can just use it yourself as a better security session tracker.

The problem with OAuth 2.0 is it’s surprisingly hard to get to this simple idea from the explosion of protocol in OAuth 1.0a. Both specs too quickly reduce to an exercise in swim lane diagram detail which ironically run counter to the current movement around simple and accessible that drives the modern web. And therein lies the rub. OAuth is more a victim of poor marketing than bad specsman-ship. I have yet to see a good, simple explanation of why, followed by how. (I don’t think OAuth 1.0 was well served by the valet key analogy, which distracts from too many important insights.) As it stands today, OAuth 2.0 makes Kerberos specs seem like grade school primer material.

It doesn’t have to be this way. OAuth is actually deceptively simple; it is the mechanics that remain potentially complex (particularly those of the classic 1.0a, three-legged scenario). But the same can be said of SSL/TLS, which we all use daily with few problems. What OAuth needs are a set of dead simple (but nonetheless solid) libraries on the client side, and equally simple and scalable support on the server. This is a tractable problem and it is coming. It also needs much better interpretation so that people can understand it fast.

Personally, I agree in part with Eran Hammer’s wish buried in the conclusion of his blog entry:

I’m hoping someone will take 2.0 and produce a 10 page profile that’s useful for the vast majority of web providers, ignoring the enterprise.

OAuth absolutely does need simple profiling for interop. But don’t ignore the enterprise. The enterprise really needs the profile too, because the enterprise badly needs OAuth.

Hey Twitter: API Management = Developer Management

Quick question for you: What matters most, the client or the server?

Answer: Neither—they are really only useful as a whole. A client without a server is usually little more than an non-functional wire frame, and a server without a client is simply unrealized potential. Bring them together though, and you have something of lasting value. So neither matters more, and in fact each matters a lot less than half.

In the API world, this is an easy point to miss. The server-side always wields disproportionate power by virtue of controlling the API to its services, and this can easily foster an arrogance about the server’s place in the world. This effect is nicely illustrated by Twitter’s recent missteps around developer management.

The problems for Twitter all began with a blog entry. Blogs are the mouthpiece of the platform. Tucked away within an interesting entry about Twitter Cards and the potential to run applications within tweets (something which is genuinely exciting), can be found a restatement of an early warning to developers:

“developers should not ‘build client apps that mimic or reproduce the mainstream Twitter consumer client experience.’”

Ominous stuff indeed. This was quickly picked up on by Nick Bilton writing in the New York Times Bits blog, who pointed out that the real problem is that Twitter just isn’t very good at writing client-side apps that leverage it’s own API. Stifling competition by leveraging your the API power card can only alienate developers—and by extension the public who are left with a single vendor solution. Suddenly, it feels like the 1980s all over again.

This ignited a firestorm of concern that was well summarized by Adam Green in Programmable Web. Green acknowledges that API change is inevitable, but points out that this is something that can be managed effectively—which is not what Twitter is doing right now.

The irony of the whole thing is that in the past, by exercising its power position Twitter has actually made great contributions to the API community. In mid 2010, Twitter cut off basic authentication to APIs in favor of OAuth, a drop-dead event that became known as the OAuthcalypse. Hyperbole aside, in terms of actual impact on the populace this cut over made even Y2K look like the end of days. Given a tractable challenge, developers cope, which is really Green’s point.

What is important to realize is that API management isn’t technical but social. Win the community over and they will move mountains. Piss them off, and they will leave in droves for the next paying gig.

The thing I always remind people is that as a trend, APIs are not about technology; they are a strategy. Truth is, the technology is pretty easy—and that’s the real secret to API’s success. You see, the communications are never the thing; the app is the thing (and that is what WS-* missed). Simplicity and low barrier to entry counts for everything because it means you can get on with building real apps.

Now I can give you the very best infrastructure and tools to facilitate API community. But how you manage this community—well, that is where the real work begins, and in the end, it is all a lot less deterministic than we technologists like to admit. People are hard to manage, but communities are even harder.

If there is a lesson here, it is that APIs are really about potential, and that potential can be only realized when you have two sides—client and server—fully engaged. Mess this one up and you’re left with just a bunch of unused interfaces.