Wow, did Eran Hammer ever go off. His noisy slamming of the OAuth 2 door behind him has become a news story. I have opinions too.
First of all, if you read his (long-ish) piece, you pretty much owe it to yourself to read the (very long) comments too.
Second: I’m kind of a n00b here. I’m a crypto cretin, a PKI peasant, an attribute-exchange airhead, and have been known to confuse authentication with authorization. Having said that:
I’ve spent a lot of time, the last few months, getting to grips with real actual OAuth 2 software, and
I’ve learned over the years that when you’re in the process of first using a new technology, that’s a good time to write about it.
Disclosure: I don’t know Eran. I’ve heard plenty of strong opinions about him from people who do. You can go out and find ’em on the Net if you think it’s material.
First Take-Away · Google offers a buttload of APIs. They are used by a frightening number of people (and robots) coming from a frightening variety of software platforms. Some of them involve the interchange of large amounts of real-money value.
For a large and increasing proportion, if you want to get your app authorized for the API, it’s OAuth 2 or nothing. It works. There are prepackaged libraries, or you can go RESTful and jam POSTs and GETs at the auth endpoints. I’ve done both. Lots of people are doing this.
In particular, it works well with Android. Or, at least it will when Google Play Services releases (to all compatible 2.2-or-later devices) in the near future. I’ll have lots more to say, and open-source code to share, when that happens. But the user experience is fine, the security is good enough for our internal gorgons, and the API, while not trivial, is tractable.
And in general, it’s way better than what we offered before. Aaaaand... no passwords!
Interop? · OAuth 2 is useful today. It would be more useful if you could take the exact same code you used to authorize your GMail address to get at your Google+ history, and use it to authorize your Facebook account for your MineVille guild. Or... (radical idea) authorize your Google/Facebook account for your Facebook/Google resources!
I haven’t tried those, but I doubt it works out of the box. I haven’t the vaguest idea whether, with some evolution in software and judicious spec subsetting, it will become workable. Interop isn’t a binary pass/fail anyhow; the question is whether the cost/benefit ratio (and there always is one) makes you happy. Suppose it never really becomes practical; does that mean OAuth 2 is a failure, as Eran claims? I dunno. Not being rhetorical, I really don’t.
Enterpriseyness · One of Eran’s central gripes is the immense difficulty of knitting “Enterprise” requirements into OAuth — or any other standards work, for that matter. He’s right. The Web use cases may not be easy to solve, but they’re easy to understand. There’s a resource, there’s a party hosting it, how do you prove to that party that your HTTP GET is on behalf of someone or something which has been properly authenticated and authorized? There are variations depending on whether you’re coming from a Web server that can keep secrets or a mobile app that can’t, and whether you need long-term or short-term access, but it’s really not that arcane.
On the other hand, whenever I get into a conversation with someone on the Enterprise side, even when I think I understand the problem domain, I lose the plot, and fast. The requirements these people claim to have around both authentication and authorization are so arcane and subtle and legacy-laden that you have to be a full-time professional to even understand them.
Also, some of them seem to exist to serve goals that seem to me like a good reason to short the stock of any company wanting that shit.
Maybe it’s just that I don’t understand, which usually seems to be the case when I get into this territory. On the other hand, maybe they’re Doing It Wrong.
Having said all that, OAuth 2 may not be perfect, and may have been harmed by the Enterprise crap, but the core of Web functionality (all I care about) seems to have survived.
What To Do With the Spec? · It has a new editor. The IETF is meeting next week (In Vancouver! I’m going). So I’ve been asking around, both inside Google and among others I respect, and people are singing the same song about the core OAuth 2 stuff:
It’s done. Stick a fork in it. Ship the RFCs.
Standards-Making · It’s easy to conclude that Eran’s pissed at the IETF. That’s a bit unfair; to start with, he seems to be pissed at everyone, and if you dive into the comments, he has some reasonable things to say about the IETF.
This hasn’t stopped a bunch of pomo Web π.0 hipsters from leaping in and shaking their heads about the suckitude of the IETF. Those guys can blow it out their shorts.
Standards-making is a boring, bureaucratic, unpleasant process, infested by difficult people and psychopathic institutions. Some “standards” turn out to be useful; most are ignored; some are actively harmful. And looking at which organization the standard came from turns out to not be very useful in predicting what’s going to happen.
And the IETF has, more or less, designed the Internet. Which said hipsters are now going to use to tell me I’m clueless. Ever hear of “irony”?
Comment feed for ongoing:
From: Christian R. Conrad (Jul 29 2012, at 22:42)
Two things:
1) If you call that "going off" and "noisy slamming", you must have grown up in an utterly hushed environment.
2) You exhort us to read the comments, as if they somehow disprove his point; in fact, thogh, the overwhelming majority seems to be agreeing with him.
[link]
From: James Roper (Jul 30 2012, at 00:13)
I'm not sure if Google is a good example of a successful OAuth 2 implementation. It is successful, it works great, high money value services are using it, no doubt there. But it's not a good example to use when judging whether OAuth 2 itself is successful. Google could implement any spec they like, they could even make their own up, Google has enough of a demand and community around its APIs that whatever was lacking in the way of clients being able to talk to it would soon be available as an open source project, even if Google didn't write it. I don't think Google uses spec compliant protocols because they need to worry about interop with their current APIs, they use spec compliant protocols out of principle, because it benefits the web (and Google) in the long term if the web is built on open standards.
The interop requirements of OAuth matter to the small organisations - the startups, the open source projects. The people that don't have the resources, demand or community around their APIs to be able to expect that people will just build whatevers lacking and release it as open source. These people need a protocol where they can say to consumers of their APIs, "just use X", and the consumers just have to use X, and it will just work. They want to provide a server side implementation that doesn't require them having to read 10 pages of security considerations in order to ensure that they get it right. I've done a lot of OAuth 1, and it does just work (once you've got the implementation of the spec right, but you don't need to do this because there already exist libraries written by people smarter than you that get it right). The security considerations are simple and well set out, which maximises my chances of getting my server side implementation right.
I haven't used OAuth 2, so I can't comment on it. But if what Eran says is right, then it's completely understandable why the protocol works successfully for Google, while at the same time may be screwing startups and open source projects.
[link]
From: Chris Adams (Jul 30 2012, at 06:25)
My question: how many of the people you talked to have implemented at less than Google scale? I think there's a real concern in moving further away from a web which can be implemented by small teams, although there's certainly an interesting discussion about whether security trumps that.
Also, while I share a certain dislike of people slamming the IETF it does seem like the group has been most successful codifying known-win protocols. There's a reason much of this discussion is happening on Twitter or Google+ and it seems hazardous to the open web if groups like the IETF begin to acquire a reputation for slow enterprise-y standards disfunction. I'd hope this piece at least spurs some action to demonstrate that this isn't the case.
[link]
From: Andrei (Jul 30 2012, at 23:23)
You're clueless. 'Nuff Said :))
[link]
From: len (Jul 31 2012, at 06:23)
Maybe the web is simply bad for business?
In conversations where no side can make sense of what the other is saying, there is a significant likelihood they have nothing in common.
How long did it take the SGML community to realize they were in the document publishing business while the web was in the business of sending messages? How much longer has it taken to realize that no matter how many layers of abstraction are applied, these really aren't the same things?
You aren't clueless. You smell funny. ;)
[link]
From: Mike Langley (Jul 31 2012, at 06:24)
The simple fact is that the IETF is "SUPPOSED" to be a group that doesn't serve the interests of one group over another. The issue we see here is that those people who were brought on to upgrade the standard were BIG MONEY Corporations who serve the Enterprise while the OAuth standard was originally designed to be an easy to implement standard that ANYONE, not just big corporations, could pickup and use. Now the Web Community is feeling as though big money enterprises have high jacked their OAuth standard for their own ends and the IETF was a party to this.
[link]
From: egor homakov (Aug 01 2012, at 09:28)
http://homakov.blogspot.com/2012/08/saferweb-oauth2a-or-lets-just-fix-it.html wdyt about this?
[link]
From: Blessed Geek (Aug 11 2012, at 19:55)
You wrote, "Google offers a buttload of APIs".
The idiomatic phrase I normally hear is boatload rather than buttload.
Did you mean to compare the carrying capacity of a boat vs that of a cigarette butt (I presume that is the butt you are referring to)?
[link]