Again it's very hard to read the small grey text on white background.
The CSS is actually using "dimGrey" for text. DIM! Ironic
OAuth 2.0 and the Road to Hell
51–60 of 73 posts
Re: OAuth 2.0 and the Road to Hell
#52Having written client code for multiple OAuth2 implementations, I can tell you: it's a total clusterf$%k, and for exactly the reasons Eran outlines: the oauth spec is a giant ball of design-by-committee compromise and feels exactly like the disaster that is XML web services and it's technologies. We would be better far off it a single company/dictator (like, shudder, facebook) came up with a simple, competently desig…
I think the obvious next step was / is to make OAuth 1.0A into OAuth 1.1 by mandating TLS/SSL and declare the SSL-mimicking parts like the timestamp, nonce optional (i.e. ignored). Anyone can just do it by fiat, since it will be backwards compatible with OAuth 1.0A clients. They'll just send the proper timestamps and nonces, but you are ignore those fields.
I found those fields were 90% of the problem with OAuth 1.0A implementations. Maybe there's security value in those parts in an SSL environment I am missing, but I doubt it since SSL does the exact same thing.
Re: OAuth 2.0 and the Road to Hell
#53We at Zapier have seen it all when it comes to API's. IMO, the biggest poison around OAuth are options. Optional grant types, various refresh token options, miscellaneous state and scope options, etc...
What is the point of a standard that cannot be implemented the same way twice? It's insane.
That said, most smaller vendors stick to the sane bits, its the big guys like Intuit or Microsoft that over-engineer their auth and pull out every fiddly feature in the spec.
Re: OAuth 2.0 and the Road to Hell
#54I've worked on standards committees off and on for many years, and his experience seems typical of the issues that crop up. There are many problems with standards groups and the way that they work. One major one is that, often, the participants come from different areas with different perspectives and visions of the outcome. Since participants rarely go to work with a firm set of agreed upon requirements or use cases…
"There's rarely any working code,..."
Once upon a time, the IETF claimed to be interested in "rough consensus and running code". "Rough consensus" went out the window a long time ago; I suppose running code had to follow sometime.
Re: OAuth 2.0 and the Road to Hell
#55pluginitis strikes again
Re: OAuth 2.0 and the Road to Hell
#56I don't understand any of this. Microsoft develops and publishes 'protocols' (used lightly) and everyone hates them because they are pushing workable code out on everyone else... Bunch of people in a committee take three years trying to build the security token system to end all security token systems and have yet anything to show for it and we are sad? Why are people trying to do this anyway? oAuth is just an idea.…
"I don't understand any of this. Microsoft develops and publishes 'protocols' (used lightly) and everyone hates them because they are pushing workable code out on everyone else..."
Have you ever tried to write an interoperable authentication system using Active Directory? I'm particularly thinking of the UDP LDAP query and the multiple-byte-order (little-endian and big-endian!) response.
"Hey here's a really good way to handle things and if you do it this way it has some really great benefits."
Because it doesn't really work unless everybody does it the same way.
Re: OAuth 2.0 and the Road to Hell
#57Earlier quoted context omitted.
If I were ever involved in a standards process, my gut feeling is that I'd want working code for all serious proposals. Does that seem feasible? Perhaps the WG would produce a set of use-case prototypes which proposals are built on.
Or at least require each and every voting member to implement the standard in a freely chosen programming language. On second thought... Might not work so good for large standards as HTML5 though, writing your own parser, renderer and layouter :)
Or maybe only browser makers should be deciding what HTML is?
Re: OAuth 2.0 and the Road to Hell
#58Hang on a minute, from where I'm standing as a client developer OAuth 2 is much better than OAuth 1. Firstly, reducing the burden of tricky and unnecessary crypto code on the client is useful. Secondly, some of the article's points don't even make sense, like saying tokens are necessarily unbounded, which isn't true. The issuer can easily include the client_id in the token and check for its revocation when used, as i…
Tricky and unnecessary crypto code: you mean HMAC, or something else? I've written code for Amazon EC2 that used HMAC and it wasn't too bad, and I'm now trying to evaluate whether to use OAuth 2, OAuth 1 or something else. Is there other cryptographic coding in OAuth 1 apart from the HMAC signature?
The biggest problem I had with OAuth 1 was that if you messed up anything chances are all you got back from the server was "Signature Invalid".
You're then stuck trying to find out where you had gone wrong with no guidance. The last time was due to an incorrect content type on the post. A coworker accidentally had the key and secret the wrong way around.
Both scenarios has the same error and you're often stuck groping around for a solution.
Re: OAuth 2.0 and the Road to Hell
#59It saddens me to see OAuth 2.0 in this state. As someone who’s made really minor contributions to 2.0 (and thus listed as a contributor in the spec), I have been really looking forward to it being finished and ready for production use (where production use means no more drafts). I stopped following the mailing list last year because most of the threads seemed all too familiar or out of my realm of knowledge to contri…
please write this up. I gave up trying to figure it out myself.
Re: OAuth 2.0 and the Road to Hell
#60> The enterprise community was looking for a framework they can use with minimal changes to their existing systems, and for some, a new source of revenues through customization.
That right there is what killed OAuth 2.0. From day 1 these members didn't have the specification as the highest priority. They were only thinking of how the specification could serve their own ends. This isn't unique to the enterprise world, but that mindset has more than its fair share. The web community represented the group that put the specification as it's highest priority. When the specification was perverted, they left.