
OAuth Has Ruined Everything - prostoalex
http://developer.telerik.com/featured/oauth-has-ruined-everything/?imm_mid=0dac54&cmp=em-web-na-na-newsltr_20151021
======
hlieberman
There was a fantastic protocol that really could have replaced much of the
problems that OAuth has, while providing its users more privacy: BrowserID,
aka Mozilla Persona.

Sadly, it got effectively gutted by the Mozilla Foundation due to lack of use,
and even Mozilla has stopped using it most places in favor of Firefox
Accounts.

~~~
acabal
I'm really sad Persona got abandoned so quickly. Mozilla made some strange
decisions in how it marketed and supported it, too: "Persona" was already the
name of their browser themeing engine (or was it the other way around?), I
don't remember there being a Chrome or IE plugin for it, I don't think any of
the Mozilla-branded sites (like addons.mozilla.org) ever used it, and after
just a year it got unceremoniously dumped.

Everyone I talked to said it was a great solution and they were really
interested to see where it would go. Why did Mozilla make so many weird
decisions on what could have been a revolutionary technology? Is there any way
to breathe life back in to it?

When it came out I personally considered implementing it for Scribophile , but
decided not to because I didn't want to invest a lot of time in an unproven
technology. If I had seen it active and lively a few years down the road, I
would have been more than happy to bite the bullet. Maybe my attitude was a
common one, and doomed Persona to a chicken-and-egg situation. Who knows.

~~~
callahad
> _I don 't think any of the Mozilla-branded sites ever used it_

You're right that AMO never used Persona, but a _ton_ of Mozilla's other sites
used (and still use) it. MDN, Bugzilla, Etherpad, the Firefox Marketplace,
most of our metrics dashboards, etc. It wasn't a complete sweep, but we did
see pretty solid internal adoption.

> _after just a year it got unceremoniously dumped._

Longer than that. I think Lloyd and Mike hashed out the first version of the
protocol back in March 2011. The bulk of the team came together around March
2012. Most of us were moved off the project in around November 2013, so we had
closer to two years as an official project.

...wow, it really _felt_ longer than that.

> _I didn 't want to invest a lot of time in an unproven technology._

That was a big reason we didn't go further than we did. People loved the idea,
but relatively few folks were willing to actually back up that belief with
action.

We also share some of the blame: We thought we had more time to experiment
with the core protocol and product design, but with Mozilla Labs' somewhat
sudden dissolution, we were unexpectedly asked to demonstrate traction and
commercial adoption that simply wasn't there.

~~~
scrollaway
Dan, I know you are not to blame for this but I hope you can at least forward
the sentiment.

I was at MozFest last year, with one of the execs on stage talking about
Mozilla's efforts to "free the web". He went on and on for 15 minutes about it
and I swear, the only thing on my mind at the time was how Persona had been
gutted. Today's web isn't "free" if a core part of it is behind Facebook and
Twitter.

> _People loved the idea, but relatively few folks were willing to actually
> back up that belief with action._

Either Mozilla is full of it when they say they fight for the free web, or
they _massively_ misunderstand how important it is to get rid of proprietary
authentication.

If this is Mozilla's stance, Mozilla's belief, then Mozilla is the one not
backing it up with action.

Edit: Followup thoughts: I cannot get behind the way Persona was dumped.
Firefox had an atrocious market share for many years, but devs didn't dump it.
Persona can't revolutionize the web by taking down Facebook and Twitter in 24
months, and it's not good enough? Grr, there were at least a dozen other ways
to stop spending as much effort on it without outright killing it.

> _Maybe my attitude was a common one, and doomed Persona to a chicken-and-egg
> situation._

Yuuuup:
[https://bazqux.uservoice.com/forums/190752-general/suggestio...](https://bazqux.uservoice.com/forums/190752-general/suggestions/4832985-allow-
authentication-via-mozilla-persona)

~~~
callahad
In these cases it's really helpful to recognize the distinction between the
Mozilla Foundation (MoFo), the Mozilla Corporation (MoCo), and the broader,
open source Mozilla project that binds everyone together.

The non-profit Mozilla Foundation exists to support the project, and does
truly wonderful, pure work on keeping the Web open. Advocacy, education,
grants, etc. They also own the for-profit Mozilla Corporation, which is in
trenches directly competing with other browser vendors to ensure that the
project has sufficient influence to fulfill its mission.

Persona was housed in MoCo, which afforded it greater resources at the cost of
greater organizational risk.

> _Either Mozilla is full of it when they say they fight for the free web, or
> they massively misunderstand how important it is to get rid of proprietary
> authentication._

The Mozilla project is too small to fight effectively on every front; we have
to focus on areas of greatest urgency and where we have the greatest leverage.
In the instance of Persona, two major things changed: (1) Persona became less
urgent, and (2) we discovered that we couldn't credibly leverage Firefox to
boost Persona adoption.

To the first point, back in 2012 we were seeing _huge_ startups, including
Spotify and Pinterest, run without offering any means of authentication
besides Facebook Connect. The lack of traditional authentication on these
sites looked like an ill omen for the freedom of the future Web, but that
didn't come to pass. Both sites now offer email-based authentication in
addition to Facebook Connect. It's not as slick as it would have been with
Persona, but the immediate threat to user autonomy isn't there anymore. If I
had to guess, it seems like the tide started turning in late 2012 / early
2013, around the time of Mailchimp's "Social Login Buttons Aren't Worth It"
blog post at [http://blog.mailchimp.com/social-login-buttons-arent-
worth-i...](http://blog.mailchimp.com/social-login-buttons-arent-worth-it/).

Secondly, Persona's passwordless design wasn't suitable for use in Firefox
Accounts, the development of which had become quite urgent. So not only could
we not use Firefox Sync / Accounts to boost Persona's active userbase, the
Persona team suddenly found itself with domain knowledge that was quite
valuable to the Accounts and Sync efforts. Oops. :)

That said, just because we're not fighting as visibly on this front doesn't
mean we're out of the fight altogether. Firefox Accounts has an active
userbase orders of magnitude larger than Persona's. We may be able to
reintroduce a notion of federated identity into FxA at some point in the
future, which would help us break out of the "three-way cold start" that
Persona faced.

But that's all hypothetical. If anyone wants to run with these ideas, _do it!_
For the sake of longevity, I'd recommend any spiritual successors to either
establish themselves within independent foundations, or design the protocol
without the sort of centralized bootstrapping that Persona had.

~~~
rfk
> _Firefox Accounts has an active userbase orders of magnitude larger than
> Persona 's._

> _We may be able to reintroduce a notion of federated identity into FxA at
> some point in the future_

As a member of the team working on Firefox Accounts, here's one
(hypothetical!) way that might play out in practice:

* grow FxA userbase to significant size, integration with Firefox to significant quality

* allow websites to add "log in with Firefox" via OpenID Connect and get a really slick experience for Firefox users

* influence OpenID Connect ecosystem to be more of a level playing field for smaller IdPs (e.g. increasing adoption of IdP discovery and dynamic registration)

* a win for openness on the web!

Not as _big_ a win as widespread adoption of Persona would be, but a win
nonetheless.

This sort of thing isn't exactly on our concrete roadmap, our short-term focus
remains on supporting Mozilla's own service ecosystem. But be assured that
it's on our minds.

~~~
WorldMaker
Why fallback to just OpenID Connect? You could use a multi-pronged approach to
prop up BrowserID using (continuing to use) OpenID Connect as bootstrapping
fabric. Maybe along these lines:

* Merge the login.persona.org fallback login provider and Firefox Accounts (grows both userbases!); you'd probably need a nice path forward to FxA users with Persona-supported email accounts, but that may just be a matter of selling "Connect your FxA account to your Gmail account for easier password management; Here's how FxA will (not) use your Gmail information"; (worst-case you need to figure out the BrowserID protocol changes to allow individual email opt-out to a different provider. Maybe easy enough to do in the case of the bridge providers to Gmail/Yahoo as login.persona.org is already mediating that...)

* Use the Firefox Accounts "brand" for the fallback provider; this gives potentially a needed distinction between the fallback provider and the platform/tooling (so long as you can do user acceptance testing to maybe avoid confusing users), so that Persona <=> OpenID Connect as a developer brand and FxA as the consumer brand

* Setup an OpenID Connect proxy _to_ Persona/BrowserID and call that the "Login with Firefox"...

A proxy could drop in to existing OpenID Connect workflows, but really be a
wrapper around the BrowserID navigator.id. With Firefox Accounts as the main
fallback this is still seen as "Login with Firefox" button This would require
fewer changes to the auth code of existing websites (drop in next to your
Google/Facebook buttons), but then as people get used to it you can start to
encourage websites to "skip the middleman" of the Proxy and directly use
Persona/BrowserID navigator.id to back that "Login with Firefox" button.

Maybe the only twist here would be a way for other browser
manufacturers/plugin-providers to play in this space and keep the branding
friendly. An idea might be to add a navigator.id.branding spec that if
implemented could override "Login with Firefox" to show a "Login with Chrome"
or "Login with Edge" button. The trick of course there would be balancing site
CSS abilities and browser branding abilities. Doing so, however, would further
reduce the need of consumers to know/learn/interact with the Persona brand and
at that point they are just associating that button as the "browser login
button". On the other hand, if FxA is the fallback provider it seems fine to
just always have it say "Login with Firefox" and it may be less confusing that
way, but with the original goals of BrowserID it might be nice to have it be
browser/plugin-configurable solely for that reassuring "Login with my Browser"
feel.

------
broodbucket
I don't think this is a good critique of OAuth at all.

First of all, the majority of complaints aren't even about OAuth, they're
about (a specific implementation of consuming) OpenID Connect, which it
doesn't seem like the author realises he's using. JWTs aren't in OAuth 2.0.

If the author had realised this, surely when looking for libraries to assist
with the project he would've looked for an OIDC or JWT library instead of
something specific to Google. There are plenty of library recommendations on
the JWT website[1], including .NET.

It's not like OAuth 2.0 or OIDC are trivial to use, but these aren't easy
problems to solve. OpenID Connect is young, and there's still a lot lacking in
terms of library support and (probably more importantly) documentation.

I'd rather deal with the rough edges of OIDC than use SAML any day of the
week.

[1]: [http://jwt.io](http://jwt.io)

~~~
nickbauman
Agree. SAML is crazy complicated.

~~~
volkadav
The entire spec, yes, is big, but the part you actually _need_ is not that
complicated. I implemented the IdP for the new york times (there's quite a bit
of third party shit plugged into the nytimes.com web experience that we wanted
to be transparent to users) in a few weeks as I recall, and I'm not some
coding super-genius. (It was kinda hacktified and minimalistic, but it worked
at scale. ¯\\_(ツ)_/¯) Most of our counter-parties were up and running in a
week or so. Compared to the abysmal quagmire that was our ecommerce code, SAML
implementation was a total milk run.

------
copsarebastards
I have deep, deep objections to OAuth, and I hoped this article would espouse
some of them, but it doesn't. Instead, this article is basically whining about
"programming is hard" which is true but also something anyone trying to solve
serious problems got over somewhere between high school and getting a real
job.

OAuth is hard because it's _pretending to solve_ a hard technical problem
(logging in and sharing some private data securely) while _actually solving_
an easy business problem (how do we (a big company) get smaller companies to
outsource as much of their user data as possible to us). It _kind of_ solves
the hard technical problem (because bigger companies are better at hiding the
data you give them from other companies who don't pay for it, and have all
your data anyway). But if that half-assed solution to the hard problem is good
enough for you, you aren't actually trying to solve it, you're just to
persuade uneducated users you've solved it. In short, OAuth For Dummies would
be a tautological title for a book.

I've heard it said that it's okay and even desirable to outsource everything
in your business to other companies _except_ your core service. But what
service exists without users? If you can't get users to sign up for _your_
service and give _you_ their information, then I'd argue you don't even have
users. You might as well quit. This isn't a question of "what's the best way
to authorize users?" question it's a "do I even have users?" question.

~~~
tboyd47
Your comment is dead on. OAuth2 provides a way for people to log into your
service without really telling you who they are. Instead, you outsource the
task of asking them who they are to another company. But if you don't care who
your customers are, _why are you asking them to log in_?

The whole concept makes no sense. And then when you consider that OAuth2 isn't
even a protocol, but a "framework for a protocol," whatever that means. But
sites use it, and will continue to use it, because it makes signup easier for
new users.

Here is what the author is missing from is "programming is hard" angle. Yes,
programming is hard, but that in itself is not a bad thing, and it's even a
good thing if the program itself is a good idea. But OAuth2 is not a good
idea. It's not even a bad idea -- it's a framework for a bad idea.

~~~
Bognar
> But if you don't care who your customers are, why are you asking them to log
> in?

I may not care who they are, but I do care how their identity maps to
information in my system. Simple functionality such as favorites or saved
preferences doesn't require any information about the user, other than them
being able to identify themselves as someone who has previously used the site.

~~~
tboyd47
Cookies or browser fingerprinting should do the trick, with gentle reminders
to register. It's how most online shopping carts work.

I'm not saying no one should ever use OAuth2, ever. Sometimes websites have to
jump through weird hoops to get conversions. But as a web developer, it annoys
me a _lot_.

~~~
Bognar
Cookies and fingerprinting tell me that the same browser is coming back to my
website, but I don't care about the browser I care about the user. As a user
if I go to a website on my work machine, my home machine, and my phone then
I'd like my data to be available on each.

I don't have strong opinions on OAuth or any other federated identity
solution, I just think it's a specious claim to say that just because a system
doesn't care about who a user is then that system doesn't care about the
uniqueness of that user.

------
lootsauce
Totally agree OAuth sucks. Want a simple way forward?
[https://passwordless.net/](https://passwordless.net/)

For profile info: [https://en.gravatar.com/](https://en.gravatar.com/)

Why do you need someone to sign in with their third party service account? If
it's just because you want a low friction sign up / sign in think again, it is
not low friction. If its to prevent from having yet another account and
password? This could be a great option.

With OAuth There is a lot of friction on the flow and privacy concerns. "What
kind of data are they going to suck out of my account?" Last time I looked at
OAuth years ago I had huge reservations. In mobile apps it uses a web-view in
the middle of the flow. Is that web-view logging my key presses? Is it using
HTTPS? Is the cert good? You'll never know.

I ran some of these concerns by Eran Hammer (brilliant, great guy) and he had
no great consolation to give me. Not long after came his epic departure from
OAuth (Not implying any correlation.)

I went on to "invent" a new auth system for mobile based on push
notifications. I got mired in trying to patent this and realized that was
stupid. TL;DR of that project, push notifications are an amazingly secure and
targeted way to deliver auth tokens try it out! But in the end, nothing beats
the simplicity of letting go and just going with passwordless and gravatar
IMHO.

~~~
pfooti
I dunno - I get the privacy concerns, sure. But passwordless requires the user
have an email address to receive the nonce, and it requires the developer to
deal with that flow. It also requires transactional email, which can be laggy
at times - I know sometimes (rarely, but not never) my mandrill outbounds can
take minutes to actually resolve. If I'm sitting waiting for a login token to
get to my emails and it's not Right There, I'm walking.

I don't see passwordless fixing anything new that OAuth doesn't fix. Use the
basic profile grant, and the user sees the consent screen where you're just
asking for a small grant.

Passwordless works for users whose email providers are not also major OAuth
providers, which is nice, but also pretty niche.

~~~
callahad
> _Passwordless works for users whose email providers are not also major OAuth
> providers, which is nice, but also pretty niche._

You're making a flawed assumption that just because a major email provider
offers OAuth, that websites themselves will also integrate with that OAuth
provider. Yahoo Mail supports OAuth, but that's not worth a damn if sites
don't explicitly integrate with Yahoo and provide a "Sign in with Yahoo"
button.

 _That 's_ why we need email-based authentication. Because, in practice, sites
are going to integrate with Gmail and Facebook and call it a day.

(On the flipside, there's a great opportunity for Passwordless to offer
optional, transparent integration with major OAuth providers, while falling
back to an email loop for everyone else so people don't get locked out. That's
what we did for Persona, and it mostly worked wonderfully.)

~~~
aianus
> That's why we need email-based authentication. Because, in practice, sites
> are going to integrate with Gmail and Facebook and call it a day.

So what? That covers like 95% of web users right there and if some users don't
like it they can go through the full signup flow.

~~~
dreamfactory2
That's a very Western centred view. We really seem to be losing sight of the
internet as a global shared infrastructure, which was the point of the whole
thing and where the benefits have come from. On the present course we might as
well be going back to the arid experiences of fido and minitel.

------
taspeotis
The post complains about the dearth of resources for authenticating an ASP.NET
application to Google via OAuth 2 but ... Microsoft do that for you [1].

[1]
[https://www.nuget.org/packages/Microsoft.Owin.Security.Googl...](https://www.nuget.org/packages/Microsoft.Owin.Security.Google/)

I think it's thinly veiled advertising.

    
    
        At Telerik, we’re all about making the developer experience better,
        and I can’t think of a worse development experience than OAuth.
        Telerik Backend Services was designed to mitigate this sort of nonsense.
        Let’s take a look at how it works.

~~~
muzmath
A typical low quality Telerik rant followed up with product placement. After
being forced into using Kendo UI, I will never willingly use one of their
products.

~~~
stephengillie
Got a good alternative to Fiddler? Wireshark doesn't have a headers view, does
it?

~~~
amatix
[http://www.charlesproxy.com](http://www.charlesproxy.com) is great — http,
ssl, throttling, decoding, filtering, replays, substitutions... It has it all.
Works everywhere.

------
pfooti
So I guess I'll be the goose at the party, or whatever the metaphor is for the
person who disagrees with the headline.

First of all: author complains about spec and then pitches their in-house
(non-free) solution. This is something like
[https://xkcd.com/927/](https://xkcd.com/927/) in spirit, at least.

Second of all: .NET notwithstanding, there's plenty of other decent libraries
for handling OAuth. Personally, I use hapijs/bell.

Third of all: I _like_ OAuth. I like the way they handle scopes, I like the
way I can just authenticate a user by grabbing an identifier from some third-
party provider (and link together multiple social logins). I like how I can
ask for other stuff via scope grants.

I also like how I have lots of control over what my applications do. I can
grab the oauth token from [provider] and generate my own token-based
authentication system for accessing my API. I can do it all in the client, or
I can use a client-server workflow. I can grab refresh tokens and _keep_ the
oauth grant alive for longer if needs be (for example: I let my identity
tokens expire and only refresh them when the user needs to open the attach
file from drive widget, and I do that refresh request on the back end).

I'm not super-wild about relying on a single OAuth provider, which is why I
typically allow different IdPs, and depending on the project will also do
regular username / password, but man I love when I don't have to worry about
dealing with authentication. Let google handle "I forgot my password" errors,
let me focus on the rest.

I have to be careful, as there are pitfalls: you can't do token auth if you're
not always on https, since OAuth basically falls down if someone gets on your
transport stream. You have to understand how the system works and how to use
it. In other words: you have to be a programmer to use it.

That's not to say OAuth is perfect. But it by no means has ruined everything.
For example: would I rather have a better, more intuitive federated
authentication and ID validation system, or would I rather Apple allow
multiple browsers on their iOS platform so I can start using modern web tech
instead of dealing with mobile safari's foibles? I'd say mobile safari is
ruining things far more than OAuth, at least IMO.

~~~
devsquid
Yea. I found Oauth to be pretty straight forward and easy to figure out. I'm
also pretty new to this game, so I couldn't imagine people with more
experience than me having difficulty implementing it properly. The blog posts
seems more like a clever marketing scheme than a real rant against setting it
up.

------
gkoberger
OAuth2 isn't a spec. It's merely loose guidelines.

I've worked with dozens of OAuth2 providers, and I am yet to see two
implementations that are interchangeable. That's the point of a spec! All
implementations required custom code. It's absolutely insane. We need a better
way. Whatever replaces OAuth2 needs to be much more strict in how it should be
implemented.

~~~
deathanatos
In what way is OAuth2 not a spec? Both your comment and the article leave me
wanting some concrete complaint…

~~~
gkoberger
The definition of a spec is "an act of describing or identifying something
precisely or of stating a precise requirement."

OAuth2 is really just a collection of suggestions. Here's some examples:

    
    
      * What field should the token be passed back as?
      * What are the token + auth URLs?
      * Should there be a separate profile URL, or is user data passed back with the token?
      * What field is the email address passed back as? The user's name?
      * Are refresh tokens used? How?
    

These are just things I literally ran into today. There's hundreds more things
like this.

And on top of that, pretty much every single OAuth provider requires custom
code: [http://passportjs.org/](http://passportjs.org/)

~~~
mikesickler
Yep- don't get me started:

* Do access token expire and need to be refreshed at all?

* Are scopes used?

* Appropriate header values?

* Can redirect URI be overrided in auth request (my personal favorite)?

~~~
makkes
* Do access token expire and need to be refreshed at all? => [https://tools.ietf.org/html/rfc6749#section-4.2.2](https://tools.ietf.org/html/rfc6749#section-4.2.2)

* Are scopes used? => [https://tools.ietf.org/html/rfc6749#section-3.3](https://tools.ietf.org/html/rfc6749#section-3.3)

* Appropriate header values? => [https://tools.ietf.org/html/rfc6749#section-7](https://tools.ietf.org/html/rfc6749#section-7) as well as [https://tools.ietf.org/html/rfc6750](https://tools.ietf.org/html/rfc6750)

* Can redirect URI be overrided in auth request (my personal favorite)? Sth. like [https://tools.ietf.org/html/rfc6749#section-10.6](https://tools.ietf.org/html/rfc6749#section-10.6) ?

~~~
LoSboccacc
while you're technically right, did the implementers knew and followed the
spec as well? now THAT's the real problem.

most of them did, but there are quite some gaps.

then you extensions and shit to complicate matter further:
[http://hueniverse.com/2012/07/30/on-leaving-
oauth/](http://hueniverse.com/2012/07/30/on-leaving-oauth/)

I like OpenID efforts to making a OAuth 2.0 subset that works and is
authoritative, but to be honest implementing OAuth dialect isn't that much of
an issue.

now, having a single consistent user id across services beyond their email,
that's an interesting problem to solve.

but for everything OAuth one can find out libraries in many languages.

------
tiles
Bring back Mozilla Persona: [https://www.mozilla.org/en-
US/persona/](https://www.mozilla.org/en-US/persona/)

------
tacotuesday
I've arrived at the opinion that users simply cannot be trusted to keep their
own credentials safe. It's literally impossible to secure a system based on
trusting the user.

There are very successful businesses (mint.com) built around the concept of
sharing extremely sensitive credentials for some reward.

In the tutum intro video I watched yesterday, the pitchman is asking
developers within the first minute of video to enter AWS credentials into his
website I've never heard of.

If _anyone_ would balk at that suggestion, I would expect it to be developers,
yet they are so successful, Docker is buying them for meeellions of dollars.

I'm really surprised no one in the thread has yet mentioned yubico as a
solution. I like yubikeys because they are something users can't upload. Keys
are a concept everyone understands, and despite what I'm told by friends, I've
yet to lose mine. I've never lost my car/house/mailbox keys either though.

Maybe I'm odd in both respects. I keep my credentials and keys close to me.

~~~
mmebane
I found keeping my Yubikey Neo on my actual keychain to be a bit inconvenient,
but wearing it around my neck like a dog tag has worked great.

Sadly, I've been unable to convince my wife that it's worth it. She won't wear
it as a necklace or bracelet, almost never has pockets, and rarely has her
keys near her when at home. I might just have to stick an Edge-N in her laptop
and slip an Edge onto her keychain, so that when she inevitably calls
complaining she can't log into GMail from a friend's computer, I'll be
prepared...

From a development perspective, I've read through the U2F spec, and it seemed
quite reasonable. I haven't had a chance to try implementing it in anything,
though.

------
the8472
> Registering for applications is a tax that nobody really wants to pay

It's quite the opposite for me. I vastly prefer a simple signup than being
offered to sign in with an account on a 3rd party site _that I don 't have_ or
don't want associated to another site.

I like to wear more than one hat.

------
lobster_johnson
Authentication on the web is not going anywhere until browsers implement
native identity support.

The constant focus on authentication and "identity providers" in discussing
this stuff misses the fact that sites and apps, above all, are concerned with
continuity: The next time I'm visiting foo.com, I'm the same person that
visited yesterday. It's the good old session cookie.

Right now, most sites ask you to sign up with an email address because that's
the constant; but that leads to a proliferation of accounts strewn across the
Internet, each with its own password and identity data. On the other hand, the
whole idea of authenticating through a third-party provider such as Google
just centralizes identity with what ends up being a very small pool of select
providers, because nobody wants to show 42 different "login in with..."
buttons.

But all we really want is that browser can prove (cryptographically) to
foo.com that I'm "user #2048203", and foo.com can prove that it is privy to
that information. foo.com shouldn't get anything but a opaque identifier, and
anything else it wants (my email, my name, my address) can be divulged through
an API dedicated to this purpose.

The whole login problem was derailed because of _authorization_ ("site foo.com
wants to access your contacts"), which OAuth was originally designed for, was
abused for authentication. But authorization is a completely orthogonal use
case, and it's a fairly limited compared to login; I authorize an app maybe
once a month, but I login every day.

We don't need or want Google or Twitter or any third-party authority to manage
our identities. What we do need is to be able to store our sets of identities
somewhere so that all our devices can share them — Apple could offer that
through iCloud, for example, and browsers could easily give you different
options.

Apple already invented ApplePay, which is exactly this for payments. Isn't
anyone working on something like this for login?

------
mmcclellan
For fun: Why I Love Basic Auth:

[http://www.rdegges.com/why-i-love-basic-auth/](http://www.rdegges.com/why-i-
love-basic-auth/)

~~~
pbreit
But how does the consumer get the credentials in the first place? That's the
main or only purpose of Oauth!

~~~
vonklaus
I like _Simple Value_. It was a concept that a lot of people have stopped
using. You either allow a user to use your site without signing in, with extra
value for them if they do OR just provide the value proposition up front so
that they will be willing to sign in.

Obviously, this won't work if you are hocking sluggish blogspam with less
content than the titanic had lifeboats and enough javascript to track my cross
atlantic voyage. Just make shit that doesn't suck and users will sign up if it
is necessary. If there is no need to have users sign up don't have it.

Super Simple Value. Build on Super Simple Auth ^TM.

~~~
RickHull
This earned a hearty chuckle. +1 Insightful to boot.

------
sinzone
One of the folks behind OauthBible.

Have you looked into Kong [1]? We built it as Open-Source proxy (based on
NGINX) that has many out-of-the-box plugins for Authentication: including JWT
[2], HMAC and the tedious OAuth2 [3]. For example, Kong reduces the complexity
of adding OAuth2 to your services in just a restful POST request, similar to
this:

$ curl -X POST
[http://kong:8001/apis/{api}/plugins](http://kong:8001/apis/{api}/plugins) \

    
    
        --data "name=oauth2" \
    
        --data "config.scopes=email,phone,address" \
    
        --data "config.mandatory_scope=true"
    

Another alternative is Auth0.com but it's cloud based and Kong is obviously a
fully featured API Gateway that does many other things so it might be too
heavy if all you need is authentication.

[1] [https://github.com/Mashape/kong](https://github.com/Mashape/kong)

[2] [https://getkong.org/plugins/jwt/](https://getkong.org/plugins/jwt/)

[3]
[https://getkong.org/plugins/oauth2-authentication/](https://getkong.org/plugins/oauth2-authentication/)

------
BinaryIdiot
I'm curious what people's opinion of Oz is as it was created by the "Fuck
OAuth" guy aka Eran Hammer that the article refers to.
[http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-
or-i...](http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i-wrote-
an-oauth-replacement/)

------
hardwaresofton
Has anyone worked with or have a strong opinion regarding CAS?

[http://www.yale.edu/tp/auth/cas10.html](http://www.yale.edu/tp/auth/cas10.html)

It's very similar to OAuth, except way simpler to understand, and very easy to
implement (I'm working on a standalone go server that will perform
authentication, but have been dragging my feet a bit so it's not done yet --
basically the only reason it's not shipped is that it's failing tests)

~~~
jldugger
CAS is not federated. If your CAS authenticated wiki detects you're not logged
in, it redirects you to what it knows as _the_ CAS url, not YOUR CAS url.

This makes it wonderful for universities and large institutions that deploy
lots of small applications and buy third party hosted services, as you can
keep the passwords local while proving identity and providing relying parties
limited data they may need for authorizations.

But if you don't have an account my CAS setup recognize, you'll need to make
one first. And if you have one with another institution, we won't recognize
it.

~~~
hardwaresofton
Yes, CAS is primarily for that usecase, but could you explain what stops
Facebook (or some other current oauth provider) from running a CAS server and
enabling me to register a callback URL and using it to authenticate a user
visiting my site?

Maybe I'm misunderstanding something fundamental

~~~
jldugger
Well, I mean, a lot of the complaints about OAuth2 revolve around how the
system was designed for high scalability over security; OAuth tokens never
expire.

Beyond that, I'd have to think a bit. I haven't studied OAuth2 in sufficient
detail really.

------
intrasight
OMG. Give me a frickin break. OAuth is hard? Get serious, get a CS degree,
then come back here and tell us OAuth is hard.

Complaining that it is a weak standard, however, is an argument that holds
water.

------
megaman821
The author has actually just described a standard called Open ID Connect,
which is built upon OAuth 2.0 and JWT. Those same steps can be used to
authenticate with Microsoft accounts.

------
mariusmg
OAuth might not be good but this "article" is just a commercial for their
product.

------
scintill76
> only after lifting code from what’s got to be the most obscure message board
> on the internet. So obscure that I can’t find it anymore.

Side note, but this is one of the reasons I always put in a comment with a
source URL when I lift code from somewhere.

------
fkooman
[https://tools.ietf.org/html/rfc6749#section-1.8](https://tools.ietf.org/html/rfc6749#section-1.8)

```

    
    
       OAuth 2.0 provides a rich authorization framework with well-defined
       security properties.  However, as a rich and highly extensible
       framework with many optional components, on its own, this
       specification is likely to produce a wide range of non-interoperable
       implementations.
    
       In addition, this specification leaves a few required components
       partially or fully undefined (e.g., client registration,
       authorization server capabilities, endpoint discovery).  Without
       these components, clients must be manually and specifically
       configured against a specific authorization server and resource
       server in order to interoperate.
    
       This framework was designed with the clear expectation that future
       work will define prescriptive profiles and extensions necessary to
       achieve full web-scale interoperability.
    

```

So what are we waiting for? I don't think OpenID Connect is the answer here,
maybe something more in the direction of IndieAuth
([https://indieauth.com/](https://indieauth.com/)).

------
artifaxx
Implementing OAuth 2.0 client and server code in a .NET stack this summer for
a job makes me inclined to agree that OAUTH has confusing points. It
definitely is not precise enough to be called a specification, but more just
guidelines. I am quite impressed with how the author overblew the whole thing
to show off their solution, it was an interesting fusion of technology and
selling their idea.

------
jpdlla
Similar read[0] with an actual proposal replacement for OAuth at the end.
Thoughts?

[0] [http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-
or-i...](http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i-wrote-
an-oauth-replacement/)

------
reimertz
If you feel it's boring to learn how to authenticate your users, from a
security point, you should probably not do it.

Meteor.js has a very beatiful way of solving this and I strongly recommend
everyone who wants to authenticate users but don't want to know how it works
to try Meteor.js.

~~~
dvanduzer
OAuth is for authorization, not authentication.

~~~
crashedsnow
That may have been the intent, but in a (very, very) large portion of cases
the developer simply wants a way to verify identity claims. That is, verify
that you are who you claim to be. 3rd party identity providers (Facebook et.
al.) are a convenient way to do this, for both the user and the developer
(maintaining your own passwords is a pain etc). It's coincidence that these
providers choose oAuth for this, but you still end up with oAuth for identity,
not auth'z.

~~~
dvanduzer
The phrase "verify identity claims" just means "authorize". There has never
been a version of OAuth that would _authenticate_ an identity.

edit: Sorry, it's easy to understand how "verify identity claim" does sound
like authentication. What it means for OAuth, is that a system authorizes
access based on delegated authentication. So "verifying an identity claim" is
binding a local authorization event to a remote authentication event. Or
something.

------
Mimick
I made a Facebook and Twitter OAuth libraries, and I can see it sucks.
Twitter's PHP library that is linked on thier documentation is based on a
really heavy OAuth library and it's old a bit that most things their aren't
need and it seems to care that as long it works it's fine.

Facebook OAuth isn't complicated since they don't look to care about
"security" as much as Twitter do (or just Twitter trying to implement every
OAuth specification blindly). But again Twitter trust you with thier Token for
life while Facebook is for a while...

So I agree with the author except on the part when he said he came up with a
good alternative which is just a step behind.

------
segphault
OAuth is broken by design. Among many other serious issues, it's ridiculous
that Twitter and other major OAuth adopters still implement it in a manner
that relies on native/mobile client applications uniquely identifying
themselves with "secret" keys that are trivially easy to extract.

It's deeply unfortunate that so many of the people involved with the spec
chose to shout down critics and hand-wave away serious concerns until it was
too late to fix the problems. OAuth 2 should have provided an opportunity to
address the issues, and instead it just rubber-stamped many of the worst
practices used by implementors.

------
whatusername
So no mention in the article of Open ID Connect?

~~~
ForHackernews
It's even more inexcusable because half of what he's complaining about
(id_tokens, JWT, aud, etc.) is actually OpenIDConnect and isn't even part of
the OAuth2 spec.

~~~
rocha
It seems like the author doesn't realize that. OpenID Connect fills the
specification holes in OAuth 2.0 that he is complaining about.

If he had used an OpenID Connect library, his life would have been a lot
easier.

------
zkhalique
You shouldn't have to "Allow" a big provider like Facebook or Google to share
your first name, last name and sex with a website, just so they can display it
back to you.

Fred Wilson spoke about the rise of decentralized identity:

[https://www.youtube.com/watch?v=R43OKYmGbhU#24:00](https://www.youtube.com/watch?v=R43OKYmGbhU#24:00)

Do you think such a thing exists successfully yet? Anyone heard about good
implementations?

------
adimania
From implementation standpoint, I frequently use Google Auth and a bunch of
their APIs. At least for Python, I can confidently say that they are not at
all painful. Yes, there is fragmentation between different oAuth providers but
unless you are writing oAuth library yourself, you may not need to face these
problems ever. Fyi, I am not using any oAuth lib but then I only use google
auth for my app, not fb or twitter.

------
crusso
I'm surprised I don't see more buzz about Steve Gibson's SQRL authentication
system during discussions like this. It seems lightweight, simple, and fairly
well thought-out.

[https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

------
resonanttoe
"It’s a sentiment that’s so common, it has it’s own Twitter account."

So does Texts from Dogs.

Twitter is not a good measure for anything.

------
al2o3cr
See, and here I was thinking that people who whine about technical complexity
without understanding it just to push their company's product was "ruining
everything".

Don't get me wrong - OAuth is neither fun nor straightforward. But making
"yuck" faces at the details isn't helpful.

------
devsquid
lol.... I implemented both Google and Facebook's Oauth as a complete noob. It
was super easy. Like literally its a button and a few lines on the client and
a few GET/POST requests to double check the user says who they say they are on
the server side.

------
steviee
Deal with it. Want to use a framework, learn how to use it properly,
especially if it's authentication/security related.

Programming is hard. You won't learn anything about the technology by only
using high level point-and-click libraries and IDEs.

best regards, Steviee

------
Luker88
Will anyone that is interested in authentication protocols participate at the
Chaos Communication Congress late this year?

I might present a new solution to this OAuth madness, and I will be looking
for people to help me finish the project.

------
homakov
See Homakov edition of OAuth, it's simpler and more secure
[http://www.oauthsecurity.com/](http://www.oauthsecurity.com/)

------
mixmastamyk
And if you think it ruins the user experience when a person is involved, it's
even worse when if you need to automate api calls.

------
dboreham
Disappointing article. The executive summary could be "software development is
hard". Well, we knew that.

------
itaysk
Isn't OpenID Connect supposed to solve this? (don't know if it actually
delivers though)

------
rynop
I hate OAuth [2.0] as well.

So how do you do twitter? They don't have a full JS client side
implementation..

------
ghshephard
I for one, am very happy about this. Difficulty with centralized logins
encourages sites to maintain their own ID system, which, along with mailinator
and tools like 1password, allows people to trivially generate separate
logins/email accounts/passwords for each site that they visit.

~~~
hlieberman
That seems rather like throwing out the baby with the bathwater. If there was
a strong federated identity provider, there would be less crappy passwords out
there.

Despite what it might seem like from HN users, the vast majority of people
don't use password managers.

~~~
arbitrage
If there was a strong federated identity provider, there would be one massive
target for abuse and attack.

If there was a well written protocol and library to help with the independent
federation of identities, that could be used by anyone, that would truly help
the security of the vast majority of people.

~~~
Pharaoh2
Oh, do you mean like the massive target for abuse and attack that are password
managers?

~~~
dvanduzer
Password management software centralizes the credentials of a given user. But
each instance of the credential database is highly decentralized.

So it's only a massive target if you then recentralize those credential
databases on a cloud storage service, for example.

Attacking the security of a password management system is different than
stealing the credential database.

------
Shorel
Damn, and I was so busy hating SAML and hoping next system would use OAuth.

------
arca_vorago
While I have my issues with OAuth, I think it depends on the use case more
than anything. For example, I have written a custom ticket system for my
current company, and since they have drank the google coolaid, everyone has a
google apps account, so using OAuth2 to provide an easy login that doesn't
require the often clueless users to remember yet another password. (working on
pushing pass management, yubico integration and other two factor). It was
simple to implement, gives me information that is helpful (the person who
submits the ticket doesn't have to tell me who they are, I already know.), and
just works.

On the other hand though, I have two side projects at the moment. A reddit/hn-
esque news site dedicated to logical analysis of stories, and an Unreal Engine
4 FPSRPG game.

For the game, I really want to encourage good security, both for accounts (the
game website accounts) and for game login (game login accounts). Looking at
the issues that the major MMO providers ran into, and for example, Blizzard
finally come out with the Battle.net authenticator, but adoption was fairly
low, but the important part is for the people who valued their account
greatly, it was often worth the overhead. Besides that though, there was just
a simple in-house auth. I don't think anyone would want OAuth to login to an
MMO, so there it's not even an option. The alternative I have thought of is
instead of a physical dongle authenticator, having some sort of two factor
built into the login portal. While it doesn't offer the same protection as a
dongle, it would be more than the simple user/pass combo to help reduce
compromised accounts.

For my news site on the otherhand, I am struggling to decide what kind of
logins to allow/seek. Since it would be a social type of site, OAuth could be
useful for people who want an account but don't want to sign up for yet
another thing. As a privacy conscious person though, it raises lots of privacy
and user identity concerns. Reddit free-for-all style user-creation though
seems to be too apt to be abused in all kinds of ways, but then HN has a
similar system but then prevents that with restrictions on top. (which I think
would falter under the same user-load as reddit). In the end I think the free-
for-all is probably inevitable, especially if I want to allow tor connections,
and restrictions will, like hn, have to be placed on top.

A lot of that is design related. Stories would be wikipedia-esque in that some
users could edit, and comments would be a separate section, and I think that's
where slashdot style random mods and perhaps user points over time would give
good commenting users ability to then do edits... I still haven't ironed all
that out yet.

The bottom line is that it's all about use case. And while OAuth isn't
perfect, sometimes it works just fine, and in others it won't. Use the right
tool for the job.

