Slashdot Mirror

← Back to Stories (view on slashdot.org)

OAuth 2.0 Standard Editor Quits, Takes Name Off Spec

Posted by Soulskill on from the none-of-us-are-as-dumb-as-all-of-us dept.

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.'"

12 of 101 comments (clear)

  1. WordStar? by jabberw0k · · Score: 3, Funny

    What's WS-* supposed to mean... WordStar? I almost thought, some geek reference to a VMS error message... (%WS-X-XYZZY) but surely not?

    1. Re:WordStar? by Anonymous Coward · · Score: 5, Informative

      It references the plethora of crappy standards created during the SOAP era. (WS-Security, WS-Routing, WS-Addressings, WS-YourMom)

    2. Re:WordStar? by luis_a_espinal · · Score: 4, Informative

      I have never seen "ws-*" before... reference please?

      Ask and ye shall receive.

      http://en.wikipedia.org/wiki/WS-*

      http://lmgtfy.com/?q=ws-*

      Courtesy of wikipedia and google.

    3. Re:WordStar? by dkf · · Score: 5, Informative

      What's WS-* supposed to mean...

      It refers to the plethora of web-services specifications, most of which take a fairly complicated protocol (XML over HTTP) and add huge new layers of mind-boggling complexity.

      You don't ever need WS-*, except when you find you do because you're dealing with the situations that the WS-* protocol stack was designed to deal with. When that happens, you'll reinvent it all. Badly. JSON isn't better than XML, nor is YAML; what they gain in succinctness and support for syntactic types, they lose at the semantic level. REST isn't better than SOAP, it's just different, and security specifications in the REST world are usually hilariously lame. Then there's the state of service description, where WSDL is the only spec that's ever really gained really wide traction. WS-* depresses me; I believe we should be able to do better, but the evidence of what happens in practice doesn't support that hunch.

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    4. Re:WordStar? by Anonymous Coward · · Score: 4, Insightful

      REST is better than soap because it uses the features of the transport instead of ignoring and duplicating them in an opaque fashion. SOAP is like having every function in your program take a single argument consisting of a mapping of arguments. Or a relational database schema with only three tables: objects, attributes, and values. In other words, SOAP is an implementation of the Inner Platform antipattern.

    5. Re:WordStar? by Anonymous Coward · · Score: 5, Insightful

      As a regretful author of several WS-* specs, after I got sucked into the vortex of IBM and MS when they passed too close to our academic lab, I felt exactly as Eran Hammer stated in his blog. He wrote, "There wasn’t a single problem or incident I can point to in order to explain such an extreme move. This is a case of death by a thousand cuts, ... It is bad enough that I no longer want to be associated with it. It is the biggest professional disappointment of my career." I have used so many of those same phrases in reflecting on my experience with other veterans of that period!

      And I'll tell you, XML and SOAP have no semantics either. They simply have a baroque shell game where well intentioned people confuse themselves with elaborate syntax. XML types and type derivation are syntactic shorthands for what amounts to regular expressions embedded in a recursive punctuation tree. There is absolutely no more meaning there than when someone does duck typing on a JSON object tree, particularly after the WS-* style "open extensibility" trick is added everywhere, allowing any combination of additional attributes or child elements to be composed into the trees via deployment-time and/or run-time decisions.

      As a result, I am rather enjoying the current acceptance of REST and dynamically typed/duck typed development models. It is much more honest about the late-binding, wild west nature of the semantics involved in our everyday web services.

    6. Re:WordStar? by shutdown+-p+now · · Score: 3, Informative

      The problem with SOAP and WS-* stuff isn't XML. It's rather that it takes, IIRC, five levels of nesting of said XML to call a simple web service that takes an integer and returns another one. In other words, it's ridiculously overengineered for the simple and common cases, while supposedly covering some very complicated scenarios better - a claim that I cannot really verify since I've never in my life seen system architecture, even in the "enterprise", where that complexity was actually useful.

  2. a few excerpts by anarcat · · Score: 3, Interesting

    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.

    --
    Semantics is the gravity of abstraction
  3. OAuth by bbroerman · · Score: 3, Interesting

    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.
    1. Re:OAuth by icebraining · · Score: 3, Interesting

      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.

      --
      Dilbert RSS feed
  4. Ignore nothing, SOAP is awful by SuperKendall · · Score: 4, Insightful

    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
  5. Re:v1 was bullshit too by Mark+Atwood · · Score: 5, Informative

    I was there, I helped write v1.

    The reason you had to sort the parameters etc etc was because OAuth 1.0 was designed to be implementable by a PHP script running under Apache on Dreamhost. Which meant you didn't get access to the HTTP Authentication header, and you didn't get access to the complete URL that was accessed. So we had to work out a way to canonicalize the URL to be signed from what we could guarantee you'd have: the your hostname, your base url path, and an unsorted bag of url parameters. Believe me, we *wished* for a straightforward URL canonicalization standard we could reference. None existed. So we cussed a lot, bit the bullet, and wrote one that was fast and simple as possible: sort the parameters and concatenate them.

    Go yell at the implementors of Apache and of PHP. If we could have guaranteed that you'd have access to an unmangled Authentication: HTTP header, the OAuth 1.0 spec would have been 50% shorter and a hell of a lot easier to implement.