There seems to be two paths for authentication:
- Build your own solution and manage salted/hashed passwords in your database.
- Use a third party service that hands your user data over to the third party.
I'm curious what solutions developers tend to be more comfortable with and if I'm missing any options here.
Top comments (26)
In my experience, users hate having to come up with yet another username and password, so I try to avoid rolling my own. Also, as you mentioned, there are security risks associated with building your own log-in system. Many consider it a best practice for security to use log-in from others instead, see for example blog.cloudsecurityalliance.org/201..., which lists "Broken Authentication" as the second most serious security risk out of twelve. They say: "It is not recommended that developers build authentication schemes. Instead, they should use authentication facilities provided via the serverless environment or by the relevant runtime."
What to use then? It should be a system that allows users to sign in with more than just one provider. I work for Google, so I've been using Firebase Authentication (firebase.google.com/docs/auth) and have been very happy with it. It makes life easy for the developer and it supports login with Google, Facebook, Twitter and Github. I have also heard good things about Auth0, but I haven't used it myself.
I wonder if there's eventually a middle ground where social authentication can also be controlled by users. As I mentioned in another comment, the biggest downside I see to apps I build is if a user loses access to a social provider (like Google, for example), they also then lose access to your app.
This happened to me with Spotify when I deactivated my Facebook account years ago. And there was no fix but to cancel that Spotify account and create a new one.
If you want to take the red pill on digital identity this check out the concepts of self-sovereign identity and the sovrin blockchain.
I’ve toyed around with Sovrin. Have mostly used bitcoin-based decentralized identity solutions though.
As a user, I would much rather sign in with Google or Github than creating a new account with email/password. Here's my (extremely subjective) reasons why:
As a developer, it's certainly tempting to roll your own auth, because OAuth, on the surface, seems really complicated, and a database of usernames and passwords seems so simple. However, I can almost guarantee you that implementing auth with an external provider is much easier than building a truly secure authentication system yourself.
Casey, this is incredibly insightful. I especially like your point about still feeling more trust in Facebook than some random application that's asking for your credentials.
And I think you're absolutely right. Adding your own authentication solution is almost always going to be less secure of a solution. Thanks for the comment!
personally, I flip-flop on this. it is a question of who i trust least at the point where i am signing up.
when it comes to spending money it feels like a concentration risk to use a social login. it would be too much data accessible from a single breach at the social network. so i prefer a site that lets me sign-up directly with my password manager filling the forms and a strong password. the most important thing for me is that I can pay without handing over my card details (i.e., use paypal and my phones built-in wallet).
on the other hand, anything to do with coding i will use my GitHub account as having a joined-up coder identity seems like it could benefit me. career profile related stuff is something that I chose to join up via linkedIn.
asking devs how they feel about this won't give an accurate picture of how the general public thinks about things. many sites offer the choice to login via one or two social logins and also let you sign-up directly. that seems like a good hedge. i think it would make a very interesting A-B or multivariant test to offer folks random combinations on a signup page to measure what works best for a particular site.
Depends on what I am building.
I go the first path for on-premise/local stuff and the second for the rest.
Usually, I don't build on-premise solutions anymore, so it's third-party all the way.
Amazon Cognito being my poison of choice right now.
Oh the days of full on-premise solutions. I think a lot of these decentralized web protocols are trying to make that concept more portable. But it's going to take a long time. Personal servers for everyone in their pocket or on their desk? Maybe it'll happen. Until then, using cloud solutions and probably third-party is easiest.
Middle ground: we avoid writing the authentication piece, instead federating with our customers IDPs (typically AzureAD, Office365, Google - nobody has asked for Github or Social media yet..) for identity assertions, which we authorize locally in a gateway so we can enforce our licensed features. Major wins: no more password reset calls to our helpdesk (250+ per day before this), user access control remains with the customer so their starters/leavers processes work smoothly, no more complex user management stacks in every product (50% of the codebase I reckon across the business!)
As we support a number of diverse products with this SSO solution the gateway also provides a nice isolation point between customer IDP weirdness and internal services, avoiding every product having to support every weird IDP.
I'm currently using firebase for personal projects.
Firebase seems to be the go-to in a lot of cases. Do you think this is because of the pricing structure or the functionality or both?
Yeah, a little bit to do with the pricing structure. I wanted to see how far I could get without paying for anything. At first I was a bit annoyed at how large the added JS was. But in the process of building my app I discovered that it's really easy to run through an oauth flow server side, so you don't even really have to load anything clientside if you don't want to.
I have always used my own solutions for managing passwords (always hashed). Some straight to the DB others going through LDAP. I am interested in third party auth though such as github.
Thanks for the comment! I think third-party auth offers the best experience, right? But at a little bit of a cost since you don't control access as much. What I mean is that if GitHub cuts off account access, that user loses access to their account on your app too.
It's nice for the user since they have a central point of access, though it has it's issues. Say you require facebook auth and someone doesn't use facebook. Now they have to sign up for facebook just to use your site/service.
But you are right if the third party goes down or removes functionality there is nothing you can do. Using facebook as an example they have a tendency of changing their APIs with little to no notice.
This is part of why a lot of my recent projects have shifted into decentralized authentication providers. But then the experience for end users is really terrible.
We have used bare bones e-mail auth, Firebase, Auth0, & Blockstack in our previous apps.
Thanks, Prabhaav. That sounds about right. Firebase, assuming you stored passwords, can be a scary proposition. This is one of the things I'm interested in, especially. When managing passwords, you are exposing your company, right? You now have to make sure those passwords are never exposed lest you become one of the seemingly daily companies to be breached.
Justin, I think @prabhaav is saying that he is using Firebase Authentication (firebase.google.com/docs/auth), which allows the user to sign in with Google, Facebook, Twitter or Github. No need to store users' passwords.
@prabhaav , is that right?
+1 Auth0
Folks should use a zero-knowledge password authentication library such as thinbus-srp. There are then a bunch of additional security recommendations on the readme about how to increase security.
I find azureAD for auth really convenient in B2B environments.
Microsoft really does knock it out of the park on a lot of their b2b specific products.
Firebase in earlier projects, Auth0 currently.
Both very similar and easy to implement. Get Auth out of the way and focus on other important things.
That's the thing, right? When I was first learning how to code, nothing talked about auth and I'd get to the point where I felt comfortable only to realize I had no way of authenticating and segmenting users. So, now, choosing the easiest path makes the most sense.