I had been wondering what was going on with OAuth 2.0. I saw a presentation on it, with new features, coming really soon, at RailsConf like 2 years ago. Then didn’t hear much about it, and found it confusing every time I tried to look into it, what it was, what supported it, what it’s ETA is.
Apparently that’s becuase…. it’s a mess.
All the hard fought compromises on the mailing list, in meetings, in special design committees, and in back channels resulted in a specification that fails to deliver its two main goals – security and interoperability. In fact, one of the compromises was to rename it from a protocol to a framework, and another to add a disclaimer that warns that the specification is unlike to produce interoperable implementations.
When compared with OAuth 1.0, the 2.0 specification is more complex, less interoperable, less useful, more incomplete, and most importantly, less secure.
Seems like OAuth became a monster, no longer a clear spec, but a framework of many possible options and custom extension points, designed to handle any possible auth flow.
The problem with this is that 1) It becomes impossible to support inter-operabiltiy, it doesn’t mean anything to say you are “OAuth compliant” in such a case, there are too many options and extensions that can fall under this; and 2) To the extent it is an “OAuth compliant” it no longer provides any indication of actual security when one follows it, since there are so many options, and it’s quite possible to choose options in insecure ways.
It reminds me of some library mis-steps in over-abstraction at the expense of inter-operability — say, OpenURL 1.0 from pre-spec OpenURL. People working on current library specs should beware. You can come up with a beautiful complicated abstraction capable of formally describing anything there is — but that doesn’t actually end up too useful for anything but hanging on the wall and admiring, we need specs for inter-operability, and for inter-operability you need to limit and constrain, not just provide a formalism capable of describing limitless possibilities.
So what are people who need OAuth-like things to do? Eran basically remembers sticking with OAuth 1.0 for most cases.
If you are currently using 1.0 successfully, ignore 2.0. It offers no real value over 1.0 (I’m guessing your client developers have already figured out 1.0 signatures by now).
If you are new to this space, and consider yourself a security expert, use 2.0 after careful examination of its features. If you are not an expert, either use 1.0 or copy the 2.0 implementation of a provider you trust to get it right (Facebook’s API documents are a good place to start). 2.0 is better for large scale, but if you are running a major operation, you probably have some security experts on site to figure it all out for you.
But I seem to recall remembering there were some significant security flaws in OAuth 1.0, that were to be fixed in 2.0? Hmm, maybe this is what I’m thinking of, according to wikipedia fixed in an OAuth 1.0a, but I’m having trouble following what’s going on even in OAuth 1.0 (the RFC wikipedia links to says it’s been superseded by another one…. I dunno).
It’s unclear to me if Rails OmniAuth has an OAuth 1.0 library, i’ve never gotten around to using OAuth (although I have some use cases for it) — here’s what I found on github, whose readme says it won’t be released until there’s an OmniAuth 1.0… which there has been for a while. I dunno. But the strategies list on the wiki does list that as a ‘developer strategy’ that can be used for implementing OAuth for particular providers, so maybe it really is stable/released/maintained? It lists such a developer strategy for OAuth 2.0 too, unclear what it does in light of Eran’s claim that there are a bazillion ways to do OAuth 2.0.
Of course, the other option is just rolling your own custom thing to do what OAuth needs doing. If you’re a big player like facebook or google, you can probably do that. If you’re a small player, it depends on who you need to inter-operate with. The problem with that is whatever you roll yourself is likely to have security problems too, this stuff is tricky, which is one reason (in addition to inter-operability) we use standards… but Eran suggests OAuth 2.0 isn’t going to give us that, really, anyway. Le sigh.