OAuth 2.0 - What Now?

If you have been following the OAuth 2.0 spec (not many have...) you would know that the leaders of the spec have been dropping out left and right. Eran Hammer who was part of the OAuth 1.0 spec and had been working on the new 2.0 spec recently stepped away in June. See his reasons here

So where does the specification go from here? That is a hard question to answer. The biggest issue is that the specification is very 'open ended' and that leads to confusion and a lack of interoperability. Case in point, have you checked out the OAuth implementations from Facebook, Twitter, Google, 'Insert API Provider Here'? They are all slightly different. As a developer who has used these various API's it is a pain to learn the nuances of each version of OAuth that providers are using. Each has a different flow (2 legged versus 3 legged), some support Web Server authentication flows, others do away with client-credentials completely.

Case in point. Have you checked out Apigee? It is an awesome site for all things API related. Best practices, developer tools, services and the ability to create your own API Console. When you are building your console (which is awesome - I have built about 3 different web versions myself) there are 2 OAuth 1.0 options and 3 OAuth 2.0 options as well as a fail safe 'custom' security option probably there for 'other' OAuth implementations. Why does it need to be so complicated? So is the nature of the OAuth 2.0 specification, too many flows and extensions have muddied the waters.

Here at Innovo we just wrapped up our first version of our API and yes... we implemented OAuth 2.0.
It was a difficult task. We spent time reading the current form of the draft and then spent time looking at some of the public API providers of the world to try and find any standards or best practices.

In the end I am not sure we ended up with the 'perfect' solution but we stuck to the KISS principle. In my mind Facebook's API and documentation is a good place to start for developers. It is a older version of the 2.0 specification but it works.

If you are already using the OAuth 1.0 specification you may not want to upgrade. If you are starting fresh like we were, OAuth 2.0 makes sense. Even with the concerns of a fairly unstable specification, the 2.0 spec can be used as more of a blueprint to produce a secure implementation. Can it really be called 'OAuth 2.0'? Probably not. Will it be interoperable with other platform API's? No.

In the end I don't know what OAuth 2.0 really is and according to Eran Hammer... it is dead