
OAuth 2.0 and the Road to Hell - dho
http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
======
rendezvouscp
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 contribute (read: enterprisey).

I run a 1.0a service provider and write clients against it. I’m thinking about
wading through the current 2.0 draft, picking out the relevant parts to small
startups with an API, and publishing a post about how to implement the sane
parts of the 2.0 spec.

~~~
Robin_Message
Yes, that would be great, as I'm not sure there are any good docs on writing a
OAuth provider.

------
carsongross
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 designed one page authentication
mechanism, provided some libraries in the popular languages and we all just
went with that.

~~~
daveman692
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...](https://developers.facebook.com/docs/authentication/server-
side/) which conformed to the spec ([http://tools.ietf.org/html/draft-ietf-
oauth-v2-12#section-4....](http://tools.ietf.org/html/draft-ietf-
oauth-v2-12#section-4.1)) 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 :-\

------
ap22213
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, it leaves
each member room to craft their own understandings of the goals. I've seen way
too many working groups attempt to create a 'master' spec that takes into
account all possibilities. Or, alternatively, clusters of people form from
similar problem domains, and powerful clusters can take the work off course.

A second major problem is that there often is a lack of real user
participants. Standards work is as close to the dullest engineering work one
can get. Worse, it seems to attract certain types of engineers that love
building specifications. Because of this, usually the real users flee
immediately. This usually leaves a body of over-educated, overly-technical
people to argue a lot over sometimes irrelevant details. Those types of people
are definitely necessary for the standard to work in the end. But, because the
real users flee, their influence is usually unchecked.

A third reason is that working groups rarely seem to use iterative and
incremental life cycles. There's rarely any working code, often little V&V,
and participants and users often can't experiment with their ideas. As we
know, what's good in theory, sometimes doesn't work well in practice.

I think there are systematic reasons much standards work fails. The 'design-
by-committee' outcomes arise from 1) lack of firm use cases to bound the work,
2) dissimilarity between participants, 3) lack of real user participants, 4)
lack of iterative / incremental cycles.

~~~
pfraze
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.

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

~~~
rfugger
Or maybe only browser makers should be deciding what HTML is?

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

~~~
brilyient
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 stupidity _and_
take action to stop it.

~~~
chipsy
I think there's a "human factors" problem in action with second systems. The
first system needs to be allowed to age before the second one becomes
worthwhile - simply because more understanding will exist of both the problem
domain, and how it was solved before.

And if it's different people doing the second one, watch out.

~~~
PLejeck
The first generation of a technology is fueled by necessity. It's often a tiny
project with only a few guys, and they portray it as "hey, I made this thing,
if you wanna use it too, cool"

The second generation is often fueled by things which were lacking or missing
in the first version. At this point, the first generation is widely adopted,
and now everybody and their brother wants their say in it.

Design by committee is bad. Design by brainstorm is good. Formality breaks
everything.

------
Robin_Message
Hang 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
it did in OAuth 1. The same is true for self-encoding: clients don't have to
issue self-encoded tokens and can instead issue unique id-style tokens with
long expiry times. As for refresh, that's unfortunate but issuers could easily
work around it if the OAuth 1 way was preferable.

In short, OAuth 2 is simpler to implement for the client in exchange for being
slightly harder on the issuer, whilst also being more flexible. Yes, it relies
on SSL for security. So does your bank.

~~~
davedx
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?

~~~
tvdw
No, the HMAC-SHA1 signature is the only crypto needed in OAuth 1.

~~~
Xylakant
Like literally every programming language should have an implementation of
HMAC-SHA1 around and lacking that, at least a SHA1 implementation. It's pretty
trivial to build HMAC-<HASHFUNCTION> if you have <HASHFUNCTION> around. A
working python implementation is literally 12 lines long.

Now if you don't have a SHA1 implementation in your programming language,
that's a different problem.

------
pjzedalis
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...

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. Hey here's a
really good way to handle things and if you do it this way it has some really
great benefits.

Why aren't these things like javascript frameworks where everyone has an idea.
I don't think it's practical that every sdk and framework will use one
security system that was agreed upon. It's just not going to happen. Everyone
has unique requirements.

I think he's just upset that more people have concerns and needs and nobody
can compromise to solve all of them. Well yeah. Naturally. They wouldn't be
needs if people could just overlook them for someone else's idea on how to do
it. They would just be problems people are looking for someone else to solve.

~~~
mcguire
" _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.

~~~
pjzedalis
_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._

That doesn't disprove my point. Just because you don't like their approach
doesn't mean they don't get points for having an approach. So far oAuth is
vaporware and not consistent in almost every implementation yet still
effective because it's just an idea.

 _Because it doesn't really work unless everybody does it the same way._

I disagree. It's not hard to adapt to using oAuth+Twists for a given provider.
It's not like it's some secret handshake nobody knows and you can't get into
the cult meeting. It's just signing data and exchanging tokens. We don't need
a universal standard. We need a universal understanding of the problem we are
trying to accomplish and various recommendations for how you might solve it. I
think the work on oAuth is already complete.

~~~
mcguire
" _It's not hard to adapt to using oAuth+Twists_ _for a given provider_ _._ "

I'm not sure, but I suspect that might actually be my point.

------
bryanh
We 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.

------
Jach
> 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.

------
krosaen
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...](http://webcache.googleusercontent.com/search?q=cache:lDQVFkyw-
LcJ:backchannel.org/blog/oauth-wrap-friendfeed)

(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...

------
andraz
Yes, this is sad. And it happens all the time.

Exactly the same thing happened to the whole Semantic Web effort at W3C. It
basically got overtaken by enterprise and now it is of little interest or use
to regular web developers.

~~~
nl
No.

The W3C semantic web efforts were run by academics, and were never of interest
to enterprise OR to web developers.

~~~
andraz
Yes, academics too. Also I am seeing lots of very loud enterprise software
people around those standards. Yes, those are very small enterprise software
companies.

------
jaequery
somewhat, shocking. i guess i'll be moving away from Oauth, feels like a
relief and scary at the same time. what are some good alternatives?

~~~
rmoriz
there are no popular alternatives. Either you are super smart and design one
from scratch… or you stick with OAuth and hope that some of the addressed
problems will be resolved.

~~~
huragok
We need an open open-auth for the proleteriat by the proletariat!

------
JamesLeonis
> 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.

------
sgt
Interestingly I am developing a single-signon provider as we speak, and I
chose OAuth 1.0. I did it mainly because the libraries (jersey-oauth in my
case) seemed more mature for 1.0, and the fact that 1.0 is a standard, whilst
2.0 is a draft at the moment.

I do realize that it's slightly more complicated for the client developer, but
all things considered I think documenting my API in the best possible way will
outweigh the perceived disadvantages.

------
abarth
Something similar is happening to HTML5 in the W3C:
<http://blog.whatwg.org/html-and-html5>

------
nerd_in_rage
I witnessed one guy implement an OAuth 2.0 provider completely wrong (he was
accepting user credentials as client credentials, or something similar.) This
guy was smart, and just couldn't understand the spec.

Upon reading the spec, it seemed that OAuth2 is really just some rough
guidelines. Pick and choose what you need for the particular flow you're
implementing.

------
malandrew
I'd love to see OAuth 2.0 forked into a version that takes into account Eran's
comments. It's be nice if the forked version explicitly mention that it will
not make any compromises to support the enterprise and that the burden is on
the enterprise to support the ways the internet works.

If the enterprise world wants a standard, let them make their own.

------
georgemcbay
Design by committee fails again.

Maybe next time it'll work!

~~~
PLejeck
We should form a committee to discuss how to fix design by committee. Sound
good?

------
msie
Heh, why not form another committee with just the web guys and without the
enterprise guys and create your own OAuth 2.0? You'll get something done
before the enterprise guys and they'll be inclined to use your working
protocol.

------
olliesaunders
What does WS-* mean?

~~~
selectnull
[http://en.wikipedia.org/wiki/List_of_web_service_specificati...](http://en.wikipedia.org/wiki/List_of_web_service_specifications)

In short, it's collective name for many Web Services specifications that are
still heavily in use in "enterprise" world. It's a mess.

~~~
Spearchucker
WS-* is big because it solves many, many problems. It's also big in the chatty
sense because it's XML-based.

That does not make it a mess.

WS-Trust, WS-Federation etc. have _already solved_ problems that OAuth 2.0
attempts to solve, which doesn't make it bad, as Eran states. Bad is
subjective.

Whether someone chooses to use it or not depends entirely on the requirement.
Choice is good.

~~~
mikeschinkel
Choice is often not good. Consider these:

\- Choice in plug type for electrical devices \- Choice in power adapter
connection for cell phones \- Choice of driving on the left side or the right
side of the road \- Choice of location for the brake pedal in your car.

Most anything that is used to _interface_ two items, as is oAuth, is better
with fewer choices. Choices increase complexity and cost for both sides of the
connection and reduce the number of solutions that are compatible. However,
for some reason this fact is often lost on technologists.

------
krmmalik
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.

------
hippieheadcase
What was the supposed purpose for oath 2.0?

~~~
jakejake
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.

------
kyberias
Again it's very hard to read the small grey text on white background.

~~~
kyberias
The CSS is actually using "dimGrey" for text. DIM! Ironic

------
PaulHoule
pluginitis strikes again

