Hacker News new | past | comments | ask | show | jobs | submit login
OAuth Has Ruined Everything (telerik.com)
297 points by prostoalex on Oct 23, 2015 | hide | past | favorite | 185 comments

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.

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.

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

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

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

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.

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

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.

Two years is nothing for something that's supposed to go global.

For how long was CSS developed before there was large scale adoption? It seemed to be seemlingly forever people were doing table based layouts even after it was available everywhere, and it probably wasn't available everywhere until many years after its inception.

> relatively few folks were willing to actually back up that belief with action

Which in this case turned out to be the correct decision. Nobody wants to implement a dying technology, no matter how good it is technically.

Most generally wait until it is best practice among the bigger players until they implement something, uness there is a clear user need.

Great comparison.

As a sidenote, basic authentication is part of the HTTP standard, so suggesting a truly open, standards based way of identifying a user for the purpose of accessing a service/system is not such a crazy idea.

It's not a dying concept, so there's scope still there.

> Is there any way to breathe life back in to it?

At least it is still absolutely possible to use it. The servers are up, the code is working, even the gmail-integration still works. Not even I would advocate to use it as the main option on a user-facing site, but maybe as an additional option if the site tries to support everything anyways? I have a few personal projects (music-streamer, feedreader, blogengine) that all use it to login, as the only option. It's the only thing simple enough to add without having to store passwords. Serendipity has a plugin to use it to login to the admin backend, same seems to be true for wordpress. It may be a zombie, but it is walking one.

Maybe that is the way to keep it alive and give others a chance to pick it up. If not, at least I had some years of having the login-problem solved for myself with almost no work required.

I remember hearing people were super-excited about it, and I kept thinking "It's a theme-customizer for your web-browser. Neat, but why is everyone going crazy for it? What's the big deal?"

Sadly, I never looked into it to find out more until after it was canned.

> I don't remember there being a Chrome or IE plugin for it

It never needed them. It was designed to work without them. I agree, it was great.

'Persona' has other meaning in Spanish, in a way that makes it hard to market for any Spanish speaking country.

Please take what we learned with Persona and build upon it, much like we built upon lessons learned from OpenID and OAuth.

The Web needs this. As long as we keep trying, one day, someone will get it right.

You know, you're one of the people in the best position to start a "New Persona" project — it's not something just anybody can pick up. You know what went right and wrong in Mozilla's approach both on the social and technical side. You also know how to best leverage the existing Persona userbase (eg keeping some backwards compatibility).

I would love to donate my time for a cause like this and I know I'm not the only one. Shoot me an email if you ever go through with it.

I would also love to help out. But I also refrain from starting that on my own. "New Persona" (or "Persona NG?") should be started and managed by somebody who knows what they are doing.

It would be really great if some Persona insider would provide an umbrella for this and review the activities, if they they don't have the time to do the actual work. I'd love to join such a project.

There wouldn't need to be a new version of any sort, Mozilla released the Persona project to the community. It can still be improved upon.

I would also like to help with reigniting Mozilla Persona.

Is there a lessons learned / recommendations for the next attempt writeup?

https://wiki.mozilla.org/Identity/Persona_AAR is a pretty good place to start.

Thanks. I hadn't seen the comment linked to before, https://news.ycombinator.com/item?id=7364465 most informative explanation I've seen.

How do you make the persona brand invisible, while still giving users some visible feedback that they aren't sending their global password to random site x?

Persona didn't have the notion of a global password -- the ideal flow had you authenticating with your email provider, on their domain, which was often completely transparent in cases where you were already signed in to that provider.

Try logging into 123done.org with whatever you want @mockmyid.com to get a sense of what that would ideally look like. My talk from PyCon 2013 goes into a little detail about how the protocol works: https://www.youtube.com/watch?v=nJff23UdNAI

With most email accounts being provided by gmail, outlook, and yahoo, I don't see auth via email domain ever happening.

Why? Gmail is already supporting that.

The question is how do you effectively communicate that to users without establishing a Persona brand?

Mozilla in the early days demoed a shiny proof of concept of how good the user experience could be with native support in the browser. [1] They never shipped this, so there was no carrot for websites to implement BrowserID/Persona, and websites struggled with the bad UX of the fallback. I don't know why they seem surprised that websites didn't take the plunge before Firefox did.

[1] http://www.extremetech.com/wp-content/uploads/2011/07/firefo...

Mozilla only really gave it like a year before they pulled the devs. Probably to work on Hello and Pocket or something worthless like that.

Let's be fair to Mozilla. Pocket is a separate company, and Hello is definitely not worthless in the grand scheme of things... merely less useful.

Off topic:

Pocket turned up in my Firefox. I don't even know what it is, and why it's there. It weirdly replaced my Readability icon. (Goes off to read).

Okay so it's ReadItLater. Which I assume is something like Readability. Or is it bookmarking or shared bookmarking? What is it and why is it in Firefox?

Mozilla pared down their suite to a barebones browser. With the option of add-ons. Now it looks as if Firefox are adding services/features back in the browser. I think I'd prefer Mozilla work on a better bookmarking/history api.

And hopefully given a good API, I could drop in a provider that I could set up in any browser.

I really liked BrowserID. I don't understand why Google/Mozilla/Microsoft wouldn't all get behind it, because it doesn't seem worth fragmenting on...

From my limited knowledge of BrowserId, it feels slightly wrong to me to place my identity in the web browser. What happens if someone borrows my PC, or I have multiple identitiesL This is still a bit of a 'mare for me when swapping between web browsers. Perhaps you should be able to hook an identity into any running app, via an identity manager/authentication agent.

BrowserId didn't tie your identity to your browser. It tied your identity to your email address, and made it possible to have several identities to choose from.

The selling point was the browser integration. This would be especially awesome on mobile.

Well that sounds better. But perhaps a poor choice of name. VisitorId might have been more appropriate.

BrowserID wasn't intended to place your identity in the web browser, it was intended to place your identity manager/authentication agent in the browser. Your identity under BrowserID is whatever email address you wish to use, and BrowserID as a protocol is about A) how to verify that the user controls that email address, then B) how to cache that verification in the browser so that the user can easily reuse that email identity across multiple pages/sites.

The login flow for Persona/BrowserID is essentially "Which email would you like to use for this site?" and let you use the same email for just about all of them or keep multiple identities, as many identities as you have email addresses you care to use.

The weirdest part is that everytime I read about Persona, everybody praises it, and .. yet nothing. Are we masochists ?

The problem is that the first-mover is going to have to be the identity providers: Facebook, Google, maybe GitHub or LinkedIn for specific markets. Users won't trust some piddly little startup with their authentication.

And without them, no developer would use it as their sole login (who'll use your service then?) and no users will set up accounts (who's going to do that for 0 services?)

Persona works by proofing you "are" that email. Your email provider needs to adopt this. If you run your own mail server you can do it yourself, if you don't, you can register with mozilla as a fallback.

For most people that means either Google (gmail) or some other party that will run email just for this purpose (for example, Facebook creates an email address for each profile already).

The percentage of the public able or willing to run an email server is tiny. That is not a solution for any market big enough for anyone to care about.

I expected that the amount of developers wishing for persona would hint a large shop to bootstrap the network effect.. alas.

The problem is that the existing identity providers don't stand to gain much if they switched, but stand to lose their control. Lose, lose for them, thus they didn't switch.

Persona is still hosted, right? Because I plan on using it.

Does this remain accurate?:


HN link: https://news.ycombinator.com/item?id=7362613 (a mozilla employee posted this: https://news.ycombinator.com/item?id=7364465 )

I'm confused about this post:


If the goal is to keep providing this service, how has it failed? What is the goal?

For those who are interested, Eran Hammer released an OAuth2 replacement in September:

    "Iron is a simple way to take a JavaScript object and 
    turn it into a verifiable encoded blob. Hawk is 
    a client-server authentication protocol providing 
    a rich set of features for a wide range 
    of security needs. Oz combines Iron and Hawk into 
    an authorization solution. Together these three 
    modules provide a comprehensive and powerful solution."
Read more here: http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i...

I've learnt a lot from this thread, I'd not heard of Mozilla Persona before. Could it be The One Ring to rule them all?

Charles Stross has his Rule34, I propose Rule 42 is that if something exists there must be a YouTube video of it.

This one of a Dan Callahan presentation from a few years back https://www.youtube.com/watch?v=nJff23UdNAI

With Rule38 being a blend of the two.

I once posted an article about Hawk ( http://alexbilbie.com/2012/11/hawk-a-new-http-authentication... ) which is/was used by Mozilla identity API


Indeed, it does!

I'm a little bit scared of it, though, to be honest. It's a giant of a protocol, and has a lot of moving parts. I'm worried that implementation is going to be so complicated, it'll end up as OAuth 3.0.

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

Summary of crazy terms in this post: OAuth, OpenID Connect, JWT, OAuth 2.0, OIDC, SAML.

I know what what only one of these means (OAuth), and the only thing it means to me is I'm in for a world of hurt.

I agree with the author, regardless of whether his terms were correct. It'd be nice to have something safe AND simple to authenticate people with.

I agree that setting up federated identity isn't as easy as you'd like, but that doesn't mean saying "OAuth sucks!" is okay when a) it's OpenID Connect in this case and b) he's not really talking about anything that's in the spec, it's setting up with one provider with the wrong tools to do so.

There are safe AND simple systems, and you pay per user or per authentication to those companies that provide them. It's security, there's no one-click solution, you've gotta do it properly (which can include paying someone to do it properly for you).

Google's OpenID Connect documentation [1] is pretty good, and for the steps that involve code in your application, there's very likely a library [2][3] that does it for you. It'd probably take you a day to put something together without existing knowledge, and then you've got secure federated login using an open industry standard that you can easily extend to add other identity providers.

[1] https://developers.google.com/identity/protocols/OpenIDConne... [2] http://openid.net/developers/libraries/ [3] http://jwt.io

Your requirement is unrealistic. "safe AND simple" can not be if the problem is inherently complex. Security is complex.

Sure there could be third party providers that take care of the complexity and provide a service for you, but then is it safe? You could attempt to do it yourself, but then you loose the simplicity and still you don't know if it is safe.

Well, to be fair, it wouldn't be all that complex if we just had one standard instead of many many many to learn. I don't find OAuth2 as implemented by most all that complex, and I didn't really find OAuth1 all that bad either.

The web UI for persona, on the other hand...

Who on earth thought it was a good idea to have a two step for username THEN password!?

Microsoft does the same thing with many of their logins. You put in your user ID, and it uses that to know what server is going to authenticate you and forwards you to it.

> Who on earth thought it was a good idea to have a two step for username THEN password!?

I haven't used Persona, but maybe this is because not all users use passwords? Sometimes you use AD authentication, or token generators, or ...

Sure. But what percentage of users would that be? Single digits?

> Who on earth thought it was a good idea to have a two step for username THEN password!?

Google, as of a while ago.

Persona at least had a good reason for it, with not all users needing to enter a password.

Perhaps, but it seemed to do a pretty poor job of remembering me...

At least with Google, despite them being a pretty poor example of good auth UX, you only ever have to type in your password (+ 2fa code etc)

It can be safe and simple to use, while being complex on the identity provider's side of the equation. Mozilla Persona was not simple, introduced a ton of new concepts, but you only had to learn all of it if you were an identity provider. For identity "consumers", you could implement and launch into production within an hour of work.

Agree. SAML is crazy complicated.

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.

Yep. Spent basically 2 months trying to implement saml manually. We had kinda a working implementation for something else. Tried to use it. Didn't work. Ended up finding a solution that somebody published. Modified and got working for my situation. It sucked and put me really behind schedule. Doesn't matter. The other members of the project were ever further behind

Not only is it complicated, the lack of documentation and the leaky XML libraries that abound ensure that whoever ends up implementing SAML are prone to make security mistakes.

I've audited two systems that used SAML to authenticate their users, both times I found XXE vulnerabilities that let me read files from their servers with the permissions of the webserver process.

The worst part is that SAML doesn't seem to be adequately documented, and figuring out how to do various flows against it (such as allowing a user to auth into a web app, and a third party API such as OpenStack) is almost impossible to figure out.

why would you need to understand the entire SAML spec? Are you implementing a custom idp system?

Assuming you are using a well established authentication provider that has built in support for SAML? In that case it's simply a matter of configuration....

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.

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.

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

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.

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.

So don't collect any more information than you need.

Choosing OAuth amounts to a very bad assumption that you'll never care about who your users are.

I do not know who is the uneducated here, but in the case of OAuth, the other company already has the user data. What OAuth enables is to use their information to verify the user. What this post is trying to say, is that the method stinks.

> I do not know who is the uneducated here, but in the case of OAuth, the other company already has the user data.

No, they don't. Google, for example, doesn't have the entire signup list of all the users of The Old Reader, but they have a lot of The Old Reader's users, because The Old Reader outsources authorization for some of its users to Google. That's data that Google is collecting via OAuth, and you'd better believe they use that data.

> What OAuth enables is to use their information to verify the user.

That's what it enables for the OAuth consumer, but there are far easier ways of doing that. The difficulties of OAuth exist because OAuth doesn't serve the OAuth consumer's needs, it serves the OAuth provider's needs.

On the first point I think we are talking about two different things. I am not talking about the entire signup list of Old Reader, I am talking about a user of Old Reader that uses Google OAuth to access Old Reader. In this case Google already has this particular user data.

Don't agree on the second one. What it does it serves the site owner needs. They can choose to provide OAuth or not. Some provide it to make it easier for their users to login, and they also provide their own authentication otherwise, other sites use OAuth only and some sites just their own. Most see it as a benefit for their users to only use one login. The benefit for the OAuth providers are stronger relationship with that particular user.

> On the first point I think we are talking about two different things. I am not talking about the entire signup list of Old Reader, I am talking about a user of Old Reader that uses Google OAuth to access Old Reader. In this case Google already has this particular user data.

We're talking about different things because you missed my point a few posts ago when I said that the problem it solves is "how do we (a big company) get smaller companies to outsource as much of their user data as possible to us". User lists are data.

> Some provide it to make it easier for their users to login

If that's their goal, they're failing to achieve it. OAuth requires more steps than a simple username/password signup form, including going to a completely different site to give permission to log in with your data. Google/Facebook/etc. and other OAuth providers aren't stupid: they know that's not a good solution to that problem. If they really wanted to solve that problem they'd write a login library (something like Reddit's signup/login system) which would solve that problem better. The reason OAuth isn't implemented that way is that the goal of OAuth is not to make it easier to sign up and log in.

> Most see it as a benefit for their users to only use one login.

There is nothing that stops users from using one login everywhere; OAuth does not aid this in any way. I use the same login on all the sites where I don't care about the security of my account.

You have yet to make any compelling argument that users or sites which use OAuth are gaining any benefit from OAuth. The only people who benefit from OAuth are OAuth providers.

>You have yet to make any compelling argument that users or sites which use OAuth are gaining any benefit from OAuth. The only people who benefit from OAuth are OAuth providers.

I am not making a compelling argument for or against OAuth. My point is that you do not understand how OAuth works. The user is already a user of the OAuth provider. The outsourcing is not decided by the Oauth provider, it is decided by the site owner, and it is the user that decides to use this option or not.

And as stated above, this post is saying that the method stinks.

Totally agree OAuth sucks. Want a simple way forward? https://passwordless.net/

For profile info: 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.

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.

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

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

I'm not really sure I buy this premise. As a developer, it's my job to provide login options. I'm 100% on board with not providing a username / password option unless my bosses demand it and ignore my counterarguments. But I fail to see how the passwordless model is not just an equivalent case with using lots of OAuth2 plugins.

It's a neat system, don't get me wrong. I could see using it in addition to a typical suite of OAuth providers. But I don't see it as a drop-in, solve-everything replacement for OAuth2. It's really just a (node / express) library that approaches the same problems but exposes different implementation issues instead.

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

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.

Sure, lag could be a problem with some email providers, but you are not limited to email.

From the site:

"Deliver your tokens via email, text messages (SMS), or smoke signs. You can embed Sendgrid, emailjs, Twilio, or any other framework you like to get the token to your user."

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

Eh. Screw company emails eh?

yeah one time passwords have been around for ages, guess why website don't use them? because users hate those.

only banks got around it so far, and because they made the process hassle free giving out hardware tokens.

waiting for a sms confirmation sucks as a user experience and you can't guarantee fast delivery (or that the user has signal at all the time)

Is not that the same as the Steam Guard?

There are millions of gamers using it.

> If it's just because you want a low friction sign up / sign in think again, it is not low friction.

Highly disagree.

Click "Login with Facebook" -> "Oh look they just want my name and email" -> Accept

^ That's 90% of my Facebook signups; it's much easier than entering everything from scratch and then verifying my email. If your app just needs name/email/password and has no significant privacy or financial implications, for the love of god allow Facebook signups.

People should never, ever be using their Facebook logins to sign in to other applications, and developers have a responsibility not to allow that to proliferate. I wouldn't use Facebook creds to log into any application, so I sure wouldn't push that on users who don't know better.

Because? Why should I spend 2 minutes creating an account for, say, 9GAG, instead of signing in with FB with one click? Why is 9GAG irresponsible for offering me that option?

Yes, because now they are allowing a third party to track you. You may be fine with it, but most users are not aware that FB is tracking them everywhere AND that their credentials are being handed off across a third party.

Never, ever do this. We rail about banks and credit firms handing off our data but are apparently perfectly fine with handing off our users data without their knowledge to a firm with known privacy issues.

Apparently, I'm a user who doesn't know better. Thank you for taking the time to condescend to me.

You're welcome, and FaceBook thanks you for sharing so much about yourself.

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

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.

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.

I have really enjoyed Kendo UI but am now just getting into a world beyond jQuery based frameworks, what were you comparing Kendo UI to that you liked better?

My hate for Kendo is very biased, due to the fact that my use of Kendo was not by my choice, and I quickly left the company for many reasons - one of them being that the overall technical prowess was very low (programming was seen as a cost center there so this is no surprise).


I view Kendo as an attempt to create an all in one solution to UI, primarily used by 'enterprise' type companies (i.e. not very tech savvy). This is a fine goal but...

I hate the imperative syntax. The Razor based Imperative syntax for creating Kendo components is god awful. Simply look at what configuring one of those ridiculous grids imperatively looks like.

But you say, there is declarative syntax! Until you start needing some of the edge cases and you will start to find missing documentation that exists in the imperative syntax documentation but not declarative. There are countless subtle differences just enough so that you may spend hours trying to fix a damn kendo grid.

MVVM Kendo: Kendo has a half baked solution for MVVM which does not compare to other open source solutions. You are better off with using a more standard open source solution where there is an actual community surrounding the development.

I used to keep a list of all of the bugs I had found upon using declarative MVVM kendo, but it's been a long time and I will absolutely never work anywhere that uses Kendo again so I brain dumped all of my specific kendo knowledge.

When all things are considered, KendoUI trys to hold your hand very tightly, and it does a great job and spinning up complicated grids. When you want something that isn't explicitly accounted for, or combine things in novel ways - you are going to be in a world of hurt.

UI Kits I like better:

I think you will be better off with any widely used UI kit. I've played around with Material Design and Twitter Bootstrap. These are both significantly lighter weight than Kendo.

Over All Frameworks/Libraries to replace the MVVM portion:

I've fallen favor of React as opposed to Kendos attempt at databinding. There's tons of great resources out there for React so I won't even try to go into it but it's been a pleasure.

I thought bootstrap was a CSS framework and Kendo was a collection of jquery widgets?

I seperated out my suggestions into UI and Frameworks. Kendo does many things, a non-standard MVVM framework is one of them: http://demos.telerik.com/kendo-ui/mvvm/index

Kendo also gives multiple ways to initiate their widgets, one of them being the standard jquery widget way.

Also bootstrap is more than just CSS, which is why it's distributed with a JS file. Samem with material design.

Frankly, I think the approach Kendo takes trys to do way to much, and in effect they make it difficult to do beyond what was accounted for.

If you simply are creating internal tools for a business to use and don't care about aesthetics or having great control/UX experience, Kendo is possibly an easy hand held solution for your company. On the other hand, the type of company who has this as a goal is likely a terrible company to work for and will not lead to very interesting work.

That very much depends on what you're doing. For front-enders, probably yes. There are other job functions though. UI is very tedious to get done and Kendo offers an easy way out, leaving you to do your main job, be it business intelligence, custom predictive analytics or something else.

Definitely, which is why I mentioned the following:

> If you simply are creating internal tools for a business to use and don't care about aesthetics or having great control/UX experience, Kendo is possibly an easy hand held solution for your company. On the other hand, the type of company who has this as a goal is likely a terrible company to work for and will not lead to very interesting work.

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

http://www.charlesproxy.com is great — http, ssl, throttling, decoding, filtering, replays, substitutions... It has it all. Works everywhere.


Works on all major os-es, although it may be bit harder to setup. Also handles transparent SSL interception.

"Let’s take a look at how it works."

Yeah, let's not and say we did. Instead, how about we take a look at how Telerik works (satire, based loosely on my own experiences with them):

Customer: "I've found a show-stopping bug in RadFoobarWidget1... can you give me an estimate as to when you're going to fix this?"

Telerik: "You're still using RadFoobarWidget1?!? We found a bug in that control, so we rewrote the whole thing and called it RadFoobarWidget2."

Customer: "Uh. Okay. But it seems like RadFoobarWidget2 dropped features that we already depended on in our commercial product release... are you going to reintroduce those any time soon?"

Telerik: "You're still using RadFoobarWidget2?!? We rewrote that as RadFoobarWidget3... It's totally different now, but, like, way way better and stuff."

Customer: "Uh. Okay, but RadFoobarWidget3 has even less features than RadFoobarWidget2 (which totally screwed us), are you planning on fixing that any time soon?"

Telerik: "RadFoobarWidget3?!? That's so last week. Why aren't you using RadFoobarWidget4?!?"

Customer: "Sigh..."

See also: ComponentOne

Customer: So I'm using FancyWidget4...

ComponentOne: We no longer own FancyWidget4, we sold that to FancyWidgetCo.

Customer: Hi FancyWidgetCo, I'm using FancyWidget4

FancyWidgetCo: FancyWidget? That's not even a product anymore, we have a product called SuperWidget!

Exactly, there are plenty of open source libraries out there, and if you really want to see a great implementation of this in C#, then check out the ServiceStack (runs on Mono as well) authentication providers: https://github.com/ServiceStack/ServiceStack/wiki/Authentica...

It makes OAuth easy peasy.

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

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.

Yep. Projects like everyauth as a multi-oauth client (https://github.com/bnoguchi/everyauth) and OAuth2orize as an oauth server (https://github.com/FrankHassanabad/Oauth2orizeRecipes) have made our lives very simpler in recent projects. I agree that OAuth is complicated and not that great, but its definitely a huge step forward from what we had to deal with earlier!

I agree. In fact I would say "OAuth has made possible everything". Sure, something better will come along soon. But I'm quite happy we have OAuth now.

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.

OpenID Connect fixes this exact problem. It fills in the gaps of OAuth2, where it often left the details up to the implementor, there is now a well defined process for verifying identity, and it's all done using IETF standards.

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

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/

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

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

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

* Appropriate header values? => https://tools.ietf.org/html/rfc6749#section-7 as well as 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 ?

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/

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.

I think you, like the article, is missing the point of OAuth; you seem to be thinking of OpenID, perhaps OpenID Connect which is built on top of OAuth. But some of your criticisms make no sense in the context of OAuth. Have you read OAuth 2.0's specification?[1] In particular, both you and the article presume there's a concept of a profile in OAuth … there's not. OAuth can be used to control access to a profile, certainly (and my understanding is that this is what OpenID Connect does, effectively) but at just the level of OAuth, you're controlling access to a generic resource. Concepts like a "profile" might make no sense.

> * What field should the token be passed back as?

It's passed in the Authorization header.

> * Should there be a separate profile URL, or is user data passed back with the token?

This is outside the scope of OAuth.

> * What field is the email address passed back as? The user's name?

"email address"? "user's name"? These are not concepts built into OAuth…

> * Are refresh tokens used? How?

In a grant_type=refresh request. It's in the spec.

[1]: https://tools.ietf.org/html/rfc6749

Bring back Mozilla Persona: https://www.mozilla.org/en-US/persona/

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.

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.

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

That's because banks are too backwards to support something like OAuth so I don't have to share my whole damn password when I just want mint to have my balance. Hell, in Canada banks are so backwards you can barely send $1,000 online even with the password.

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

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?

For fun: Why I Love Basic Auth:


That's not user facing, and that's the subject here. In the user facing context the bigger problems are that 'basic authentication' did not support such niceties as logging out and sends the password in plaintext.

So yes, it's easy to use and simple but so is a tri-cycle and I'd hate to have to make any miles on a tri-cycle.

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

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.

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

Authentication and authorization are different concerns, and OAuth attempts to handle both in a secure manner. I love working with basic with too, but it's not a fair comparison.

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 \

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

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

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

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

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


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)

One thing I didn't like as a user, is that to a typical user on my university's installation, it was possible for any third party to invoke the auth flow in a hidden iframe, meaning they could silently log user IDs if the user was signed in to CAS, and potentially have a sort of super-cookie to track people with or discover real-life identities.

The user's recourse is to tick a checkbox on the login page to warn on each subsequent authentication. I made a userscript to always select that option and also add a shortcut key to quickly approve from the confirmation page (since it came up quite often when navigating through the myriad products that run the university.)

I did think it was cool that they allowed third parties to use the system, but wish there were some easier way to prevent abuse.

I don't have a lot of knowledge of other auth systems, but the CAS architecture did seem pretty simple -- maybe too simple for some usecases. I know my university sent extra user data (besides just the user ID) to HTTPS sites on *.university.edu, so potentially that could be used to deliver user info or tokens to retrieve more later.

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.

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

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.

Oh for those interested, here's the standalone server I've been working on (it's super rough):


While there are other versions of the CAS specification (v2, v3, v4), my implementation sticks pretty close to v1, since it has what you really need (I diverge a little because I use JSON).

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.

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.

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

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



   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

   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/).

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.

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

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.

Don't you see some contradiction between your two sentences? You're attempting to recommend something that supposedly "magically" works so people using it don't need to understand the details about authentication. Seems like the quickest way to end up with all sorts of problems.

I read it as meaning "Don't implement it yourself if you're not ready to go deep down", not "do not use already battle tested".

I read it as "don't bother with details, just use this thing here that does a lot of other things but happens to have a lib that might do it".

I think it's absolutely a good idea to use battle tested code, but you need at least working knowledge on what you're doing to apply it properly. Same thing applies for crypto in general: you generally don't implement it yourself, you generally use battle tested code, but you need to understand what you're doing. The idea that you can eliminate any of these steps and have something working properly is wishful thinking.

Haha, good point.

Like forgetting about disabling Meteor's 'autopublish' and 'insecure' packages that are enabled by default.

A bunch of different "identity as a service" type products seem to be getting more prominence (Auth0, Stormpath, and Ping Identity come to mind), too. The selling point of these seems to be that you as a developer don't want to spend all your time doing figuring it out and doing it right, so offload it to somebody else.

OAuth is for authorization, not authentication.

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.

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.

OpenID Connect [0] is "an interoperable authentication protocol based on the OAuth 2.0 family of specifications." Note this is a different protocol from OpenID 2.0.

[0] http://openid.net/connect/faq/

Yes, OpenID Connect is a protocol that builds on the authentication features developed from previous versions of OpenID, and merges it with the authorization features defined via OAuth.

It is all laid out fairly clearly in this comment on the original blog post, for example: http://developer.telerik.com/featured/oauth-has-ruined-every...

"Alternatives" such as OpenID and Persona flopped though. So it is not like there is much choice anyway AFAIK.

It's more a problem of people who know what they're doing being annoyed by idiosyncrasies than people who don't know what they're doing not knowing what they're doing.

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.

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.

So no mention in the article of Open ID Connect?

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.

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.

No there was no mention. Plus, Open ID Connect is built on top of OAuth, so I don't think the author is a big fan of connect either.

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:


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

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.

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.


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

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.

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.

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

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.

See Homakov edition of OAuth, it's simpler and more secure http://www.oauthsecurity.com/

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.

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

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

I hate OAuth [2.0] as well.

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

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.

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.

I'd be more than happy to ditch any service that required me to sign in with a third party identity.

What do you mean by "a strong federated identity provider"?

If it's a federated system, there's already more than one provider. If it's a "strong" provider, then that probably means it's a market leader, in which case there's an equally strong incentive to edge the competition out.

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.

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

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.

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

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact