Live data from Hacker News

OAuth 2.0 and the Road to Hell

hueniverse.com

41–50 of 73 posts

Re: OAuth 2.0 and the Road to Hell

#41
> With very little effort, pretty much anything can be called OAuth 2.0 compliant.

This was both a sigh of relief but also slightly horrifying when I was working on an oauth2 server in Node. It encourages a lazy "implement the parts we care about and that are required, and take shortcuts for unspecified things." I thought the separation of access tokens and refresh tokens was wrong because once you're just giving the client an encrypted string to avoid certain DB lookups later you can put whatever data you want in it (the spec doesn't care) including managing refreshes, revokes, etc. I like the idea of expiring tokens of course, but it would simplify the client significantly to just replace the currently used token with a new token issued by the server if one is returned. I recall the 'standard' flow is "request with access token, fail, request new access token with refresh token if you have one, maybe succeed, maybe get a new refresh token, if succeed request with new access token". Having the access token manage the data to refresh itself is simpler. I'd agree it's bad that token security is reduced to cookie security by default, really the whole rant is spot-on.

Re: OAuth 2.0 and the Road to Hell

#42
post #37

I'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…

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.

Re: OAuth 2.0 and the Road to Hell

#43
post #10

https://en.wikipedia.org/wiki/Second-system_effect strikes again?

This is simply brilliant. It's fascinating. I sometimes think that these people who puch for the "second system" really have no idea the problems they are bringing about. That is, it is innocent. Hate me for saying so, but there are just a lot of people working in software who lack a sense of wisdom. Folks like Fred Brooks who can see the madness are few and far between. Even rarer are those who both see the stupidit…

Don't miss this cool insider look on Netscape's second system failure from jwz and Brendan Eich: http://gigamonkeys.wordpress.com/2009/09/28/a-tale-of-two-re...

Re: OAuth 2.0 and the Road to Hell

#44
post #42
post #37

I'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…

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 :)

Re: OAuth 2.0 and the Road to Hell

#45
Might OAuth WRAP make a comeback? Bret Taylor wrote about it years ago as a simpler approach:

http://webcache.googleusercontent.com/search?q=cache:lDQVFky...

(his blog seems to be defunct, hope that's not permanent)

Seems like OAuth WRAP has been officially deprecated in favor of OAuth2.0 but given these issues...

Re: OAuth 2.0 and the Road to Hell

#46

Having 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…

The earlier drafts were much more like that. They were largely a collaboration between a few web companies who had deployed OAuth 1.0 with Dick Hardt who had written WRAP at Microsoft. One of the major design goals was producing a protocol simple enough that client developers would not have to use libraries.

I was pretty happy with this result since we could write a simple page like https://developers.facebook.com/docs/authentication/server-s... which conformed to the spec (http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-4....) and was an easy to implement explanation of authenticating a user.

But the OAuth 2.0 spec we were working off of is now eighteen months old and as Eran said the vast majority of those contributors have drifted away from the effort over this past year :-\

Re: OAuth 2.0 and the Road to Hell

#47

What was the supposed purpose for oath 2.0?

I would have been happy with things the same but simply a better "two legged" version to allow better interoperability with trusted services from native apps. Having oAuth 1 kinda bound to the browser has been a minor headache for my team. But for the most part I think oAauth 1 works well. It just needs some official specifications for usage in non-web apps to put an end to all of the inconsistent solutions that people are creating out of necessity.

Re: OAuth 2.0 and the Road to Hell

#48

It 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…

count me in

Re: OAuth 2.0 and the Road to Hell

#49
just been reading about the debacle with xml and w3c snd this whole oAuth business sounds like it's heading down the same path. Seems like the browser vendors had the ultimate say when it came to html. in terms of oAuth i wonder where the ultimate power lies because those would be the factions that need to do something right now to deal with this mess.
Post reply on HN