OAuth 2.0 Standard Editor Quits, Takes Name Off Spec

New submitter tramp writes "The Register reports, 'Eran Hammer, who helped create the OAuth 1.0 spec, has been editing the evolving 2.0 spec for the last three years. He resigned from his role in June but only went public with his reasons in a blog post on Thursday. "At the end, I reached the conclusion that OAuth 2.0 is a bad protocol," Hammer writes. "WS-* bad. It is bad enough that I no longer want to be associated with it."' At the end of his post, he says, 'I think the OAuth brand is in decline. This framework will live for a while, and given the lack of alternatives, it will gain widespread adoption. But we are also likely to see major security failures in the next couple of years and the slow but steady devaluation of the brand. It will be another hated protocol you are stuck with.'"

Comments

a few excerpts

[anarcat]

Good article, quite interesting to see the problems a community is faced when going through standards processes.

Our standards making process is broken beyond repair. This outcome is the direct result of the nature of the IETF, and the particular personalities overseeing this work. To be clear, these are not bad or incompetent individuals. On the contrary – they are all very capable, bright, and otherwise pleasant. But most of them show up to serve their corporate overlords, and it’s practically impossible for the rest of us to compete. Bringing OAuth to the IETF was a huge mistake.

That is a worrisome situation. With the internet openness being so much based on open standards, the idea that the corporate world is taking over standards and sabotaging them to fulfill their own selfish interests is quite problematic, to say the least.

As for the actual concerns he is raising about OAuth 2.0, this one is particularly striking:

Bearer tokens - 2.0 got rid of all signatures and cryptography at the protocol level. Instead it relies solely on TLS. This means that 2.0 tokens are inherently less secure as specified. Any improvement in token security requires additional specifications and as the current proposals demonstrate, the group is solely focused on enterprise use cases.

I don't know much about oauth, but this sounds like a stupid move.

OAuth

[bbroerman]

Having implemented OAuth1.0 and 2.0 services for communicating with various platforms, I was amazed at the lack of any security in Oauth 2.0. As mentioned by others, it completely relies on SSL/TLS, which is itself somewhat broken. From what I have gathered, it's simpler. That's about it. Actually, I prefer OAuth 1.0 and have modeled many of my own APIs after it.

Re:OAuth

[icebraining]

There's nothing wrong with SSL/TLS for this. Software doesn't fall for SSL stripping and you can even copy the service's certificate over and validate against that, bypassing CA issues.

Re:WordStar?

[jklappenbach]

Ignore all concerns but scalability, and REST becomes far more preferrable than SOAP. The overhead of XML -- usually an order of magnitude in data size -- can be a huge, undesirable impact. That said, there's one aspect of SOAP that popular REST specs are missing: a definition language. With the help of the WSDL, SOAP gained cross-platform client generation and type safety. REST protocols would do well to leverage this concept, at least for invocation parameter definitions. In most cases, REST result messages are encoded in JSON, where a Javascript interpreter for parsing and object model translation can be leveraged. But even then, having a documented result schema would be a huge improvement over forcing developers to inspect result sets at runtime to divine structure and content.

But, back on topic, having evaluated OAuth 2.0, I agree with Hammer's assessment. It's not a protocol, and the inability of this team to produce a viable solution will only lead to fragmentation and the failure of OAuth.