OAuth Has Ruined Everything
developer.telerik.com
developer.telerik.com
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.
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.
The selling point was the browser integration. This would be especially awesome on mobile.
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.
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.
It never needed them. It was designed to work without them. I agree, it was great.
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.
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...
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.
> 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.
* 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.
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.
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.
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.
Sadly, I never looked into it to find out more until after it was canned.
The Web needs this. As long as we keep trying, one day, someone will get it right.
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
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.
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.
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?)
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.
[1] http://www.extremetech.com/wp-content/uploads/2011/07/firefo...
"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."
Does this remain accurate?:
http://identity.mozilla.com/post/78873831485/transitioning-p...
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:
https://wiki.mozilla.org/Identity/Persona_AAR
If the goal is to keep providing this service, how has it failed? What is the goal?
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.
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
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'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.
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.
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
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.
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!?
I haven't used Persona, but maybe this is because not all users use passwords? Sometimes you use AD authentication, or token generators, or ...
Google, as of a while ago.
Persona at least had a good reason for it, with not all users needing to enter a password.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
Choosing OAuth amounts to a very bad assumption that you'll never care about who your users are.
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 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.
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."
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.)
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.
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.
Eh. Screw company emails eh?
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)
There are millions of gamers using it.
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.
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.
[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....
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.
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.
> 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.
Works on all major os-es, although it may be bit harder to setup. Also handles transparent SSL interception.
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..."
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!
It makes OAuth easy peasy.
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.
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.
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?
And on top of that, pretty much every single OAuth provider requires custom code: http://passportjs.org/
* 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)?
* 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 ?
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.
> * 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.
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.
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.
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.
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.
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?
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.
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.
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"
[1] https://github.com/Mashape/kong
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)
https://github.com/t3hmrman/casgo
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).
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.
Maybe I'm misunderstanding something fundamental
Beyond that, I'd have to think a bit. I haven't studied OAuth2 in sufficient detail really.
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.
Complaining that it is a weak standard, however, is an argument that holds water.
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
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/).
[0] http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i...
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.
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...
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.
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.
Like forgetting about disabling Meteor's 'autopublish' and 'insecure' packages that are enabled by default.
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.
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.
If he had used an OpenID Connect library, his life would have been a lot easier.
Fred Wilson spoke about the rise of decentralized identity:
https://www.youtube.com/watch?v=R43OKYmGbhU#24:00
Do you think such a thing exists successfully yet? Anyone heard about good implementations?
So does Texts from Dogs.
Twitter is not a good measure for anything.
Don't get me wrong - OAuth is neither fun nor straightforward. But making "yuck" faces at the details isn't helpful.
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
I might present a new solution to this OAuth madness, and I will be looking for people to help me finish the project.
So how do you do twitter? They don't have a full JS client side implementation..
Despite what it might seem like from HN users, the vast majority of people don't use password managers.
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.
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.
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.
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.