Slashdot Mirror
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.'"
What's WS-* supposed to mean... WordStar? I almost thought, some geek reference to a VMS error message... (%WS-X-XYZZY) but surely not?
It doesn't have to be perfect - only "good enough".
Look at all the technologies we're currently using: The X Server, HTTP, and so on. None of it is perfect, but "good enough".
So instead of moaning, do something, to improve it!
The resulting specification is a designed-by-committee patchwork of compromises that serves mostly the enterprise. To be accurate, it doesnâ(TM)t actually give the enterprise all of what they asked for directly, but it does provide for practically unlimited extensibility. It is this extensibility and required flexibility that destroyed the protocol. With very little effort, pretty much anything can be called OAuth 2.0 compliant.
Sounds familiar. For anyone following the Smart Grid work, this is exactly why Smart Energy 2.0 is a fiasco. All of our major standards organizations (IEEE, ANSI, IETF, etc.) have been taken over by bureaucratic-minded industry and government consultants -- parasites that feed first on the drawn-out work within the standards organization that results in a "flexible" specification (meaning that it's not a specification at all), then feed on any group that tries to implement the standard because they'll need the "expert" insight in order to make the "flexible" damn thing work at all.
A framework is like a set of libraries that you embed your code in, instead of embedding them into your code.
The problem is, that usually
1. that doesn’t give you the option to use only parts of it,
2. it is a vastly over-engineered mess because of the same lack of separation,
3. you can't use it with other things, because those other things don't fit into the fixed framework,
4. doesn't allow you to model your big picture for the same reason.
I've seen enough of them, no not fall for that again.
See also: "Enterprisey", "inner platform anti-pattern", "TheDailyWTF"
Good article, quite interesting to see the problems a community is faced when going through standards processes.
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:
I don't know much about oauth, but this sounds like a stupid move.
Semantics is the gravity of abstraction
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.
Logic is the beginning of reason, not the end of it.
Eran Hammer on Twitter: "The new and improved signing proposal for mac tokens was sweet and simple. One JS line. But they wanted JWT and assertions." Emphasis mine.
OAuth is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically supplying username and password tokens instead. Each token grants access to a specific site (e.g., a video editing site) for specific resources (e.g., just videos from a specific album) and for a defined duration (e.g., the next 2 hours). This allows a user to grant a third party site access to their information stored with another service provider, without sharing their access permissions or the full extent of their data.
systemd is Roko's Basilisk.
I tried to implement OAuth v1 on a mobile device. What a pain in the hole. And it all fell down once you had to get the user to fire up the browser to accept the request. There was no way (I could figure out) to handle the callback so instead it seems to have been implemented via a corporate server thereby defeating the whole purpose of it. The easiest to work with was DropBox. I never got what extra level of security sorting the parameters provided the signature would show up any tampering, it just means you gobble up memory unnecessarily.
Sorry this guy had a rotten experience after trying to help the web community.
Simplicity is the absolute bedrock of software. Every layer of the stack that adds more complexity, adds more time and resources to support. Which means at the end of the day you can't build a larger more powerful app because you are wasting time with unnecessary complexity.
The enterprise is fucked, because they don't understand the importance of simplicity. This is why they are being replaced by cloud service providers at all levels, and this trend will continue. It is an order of magnitude increase in productivity to have a giant like Google handle a million companies' emails vs. a million individual IT departments that already have too much on their plate.
Ignore all concerns but scalability, and REST becomes far more preferrable than SOAP.
You don't have to ignore any concerns. SOAP was always a bad idea, as there is nothing to be gained from it you cannot work out by the combination of the HTTP protocol with REST style access.
This was obvious even in the very earliest days of SOAP, when people at that time where noting that REST was so much more practical. I had to use it off and on with various internal IT projects but it was always a bad deal, and just about always was eventually moved to a REST style service so people could get work done.
That said, there's one aspect of SOAP that popular REST specs are missing: a definition language.
As you note, it's called JSON, and we've been using it for years. It doesn't "need to be in the spec" when everyone is doing it that way.
But even then, having a documented result schema would be a huge improvement
No, it's really not useful. It's overhead. It takes more effort to maintain such a formal interface than to have people simply consume JSON as they will. And often the parts of the system that are supposed to process those formal definitions fail. All around just a horrible block to getting things working the way you like.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I bet he died from a heart attack while plowing his twink boytoy.
I rarely laugh at these offtopic comments. The original MyCleanPC ones were kinda funny but the later ones just got too ridiculous. But this one was just short and sweet. Got a good laugh out of me.
Thanks for stating it so well.
I’ve worked on related standards and I can identify with much of Eran’s frustration. Eran’s a smart, dedicated, passionate person who has worked very hard to make OAuth work for everyone - not just those looking to profit from it. And OAuth is currently the best open standard option for securing REST-based web services today. I hope that when he thinks about OAuth, he thinks primarily about the huge contribution he has made, and not with regret. The standardization process ultimately brings a lot of competing interests to the table - often from vendors. Vendors are increasingly focused on identity as it facilitates the ‘de-perimeterization’ trend in the approaches taken to securing networks. In the identity standards process these different interests are often addressed by creating different ‘profiles’ within the standard – to address specific use cases and concerns like the ones mentioned by him and in some posts here. Once the standard is ratified (and often before) everyone goes off and creates implementations of those profiles – but usually not all of them – to suit their needs. That makes the products more complex to deploy and to do so securely – a lament that Eran expresses. Ultimately the market will decide which profiles were the most important – based on their adoption. I believe that much of Eran’s vision has been and will continue to be realized as adoption increases and OAuth profiles mature.
Everyone hates SOAP and we all understand why. REST + OAUTH is a good combination but the fact that for every single service you need a different implementation sucks. You can say it is all JSON or in some cases XML or even HTTP POST VARIABLES. But the fact is, there is no standard for REST. On the other hand, more than 10 years ago there was XML-RPC, It was dead simple to implement and it was very flexible. Once you had an XML-RPC implementation, you could call any service without the need to recode your message handling stuff. I still don't know why it haven't gained traction.
The guy may have been bright but he was a royal pain in the butt to work with.
Maybe he was hoping everyone else would resign and leave him to it.
He despised any enterprise bigger than three people and a dog and always bit the hands that fed him.
Standards-setting involves understanding the needs and constraints of big and small players not pissing on them with the holier-than-thou tone that was Eran's trademark