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.
OAuth 2.0 and the Road to Hell
41–50 of 73 posts
Re: OAuth 2.0 and the Road to Hell
#42I'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…
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
#43https://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…
Re: OAuth 2.0 and the Road to Hell
#44I'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
#45http://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
#46Having 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 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
#47What was the supposed purpose for oath 2.0?
Re: OAuth 2.0 and the Road to Hell
#48It 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…