OAuth 2.0 standard editor quits, takes name off spec | Hacker News Reader

OAuth 2.0 standard editor quits, takes name off spec

theregister.co.uk

90 pointsllambda9 comments

This is disappointing to hear. For something so important to our immediate future, OAuth 2.0 is currently a mess. There are many different versions of the protocol -- some of which aren't backwards compatible -- and losing a leader like this is only going to make the situation worse.

I think the best hope of getting OAuth back on course is getting the current spec-writers to separately right a mechanism that interfaces with Google, Facebook, Twitter and LinkedIn. After they've each done that, they can get together and talk about how to rectify the train-wreck.

Do you mind explaining why it is a mess? I'm not doubting what you are saying is true, it is just that recently I used a Clojure library to connect to Facebook, Google, and github, and the code to do so is simple and more or less the same for each site, with one of the sites being slightly different.

Is the mess on the side of a library writer's perspective? Or in running it on the server?

> more or less the same for each site, with one of the sites being slightly different

That's because the Clojure library isolated you from the vastly different interpretations that those providers have of the spec. Had you written your connectors from scratch, you would have experienced the "mess."

The solution is to come up with an OAUTH 1.1 spec that accomplishes what's really needed. The more modest version number will keep the complexifiers focused on "2.0" which will either never be finished or never be adopted.

In my view, the most important goal for OAuth 2 was mandate SSL/TLS. That means it could remove timestamp and nonce, and only use plaintext signatures. Any implementation can do this and be backwards compatible with OAuth 1.0A clients by simply requiring SSL and plaintext signing and ignoring timestamp and nonce. Many days I am of mind to declare that a wildcat 1.1.

I would like to see any changes iterate smaller, not to mention ignore enterprise use cases completely since they already have an excellent framework called SAML 2.0 and OAuth is mostly good to accelerate the development of self-served web apps (ie consumer apps and SaaS).

I don't blame him, what a mess.

IMO, a standards push of any sort needs a single, in-touch BDFL to say: "Here is how it is going to be, here are your limited options. Maybe, here are the official libraries and test suites."

The current pattern of design by committee is severely broken.

The main problem of OAuth is not really the specs: it is tendency of us engineers to implement something different - even though there is no need to reinvent the wheel.

Meaning, why does not a new service X model their implementation as Facebook - or maybe Twitter?

But no - every new service starts from scratch and tries to reinvent the wheel. Even wrapper libraries cannot keep up with all these "understanding" of the protocol.

(This rant is valid for APIs in general)

Reply on news.ycombinator.com