In 2020, for many startups, side projects, and companies, using prebuilt authentication systems the likes of Firebase, Authpack, and Auth0 can be more secure and efficient than building out their own system.
And if you think about it, it makes sense. It's not like every company writes their own JavaScript framework. Why should companies reinvent the wheel?
With that said, in this article, we will be exploring a few different options and categories for authentication.
So without further ado, let's get started
Prebuilt traditional authentication
So this is the old-fashioned standard that most sites are using. The site usually requires a username or an email and a password.
While this is the most common setup, I would argue that it can lead to lower security compared to password-less standards.
A cryptographically secure randomly generated code is much harder to guess than your average password.
But, many users prefer this method because it is what they are used to. The most popular option isn't always the best, but traditional authentication has the advantage of being well-known and recognized. Everyone and their mother understands the concepts of it, mostly because it isn't rooted in a mysterious technology. Going the conventional route allows users to be accustomed to your platform from the beginning.
So, if you don't wanna spend one of your innovation tokens (read this) or prefer familiarity with your user base, then this may be the way to go.
My recommendations
- Authpack: Extremely generous free tier with unlimited users. Great support and documentation. Stripe payments also integrated. Incredible user experience
- Auth0: Has a more enterprise-focused angle. Free plan with 7000 active users
- Firebase Auth: Part of Firebase. Includes many other options including anonymous, social login, and Phone Auth. Phone Auth limited to 10k for free
Password-less authentication
Recently, a few companies have begun offering password-less as a less risky alternative to traditional authentication.
These use public-private encryption algorithms to generate key pairs. The public key is saved to a database associated with another piece of data, often an email or phone number. Then, a “challenge” is sent, and the browser uses the private key to solve. The server sends a unique token to the browser and the transaction is over. Read about this more from one of the providers.
I reached out to DID.app for a one -sentence summary, and this is what they said.
DID.app is an Identity Provider, that authenticates users by verifying access to either an email address or securely stored private key.
Security is greatly improved by this process and the user experience may also be better, but only when they've gotten used to it. If you want to try a new, promising technology, password-less may be the route to go down.
My Recommendations
- DID: 1,000 users. Unlimited applications. Reasonably priced and very open about the technology
- Auth0: Enterprise-facing. Has support for password-less (obviously)
Social Login
This seems to be a perfect solution for both users and companies. Users get a much quicker registration process and companies barely have to manage their authentication or paying for it.
These usually rely on the 0Auth standard to authorize the Application
Social login can also end up allowing some great concoctions, such as SOA (Son of Anton)
You can implement these yourself fairly easily using passport (which is sponsored by Auth0) and Express or use one of these platforms. Implementing your own solution with passport is relatively safe, and gives you the flexibility of adding pretty much any social provider. If you need an integration with a lesser-known service, this may be your only feasible option.
My Recommendations
- Authpack: Only four options currently (Google, Facebook, Slack, Github), but the creator is open to adding new ones upon request. Same features mentioned earlier
- Firebase Auth: Many providers supported, but most likely harder to get one added
- Auth0: Unclear what social login providers are supported. Sign in with Google supported
Implementing your own
Building your own authentication system for production is not recommended. There are many security risks involved in doing this. Let's just say it's not a task for the faint of heart.
If you do want to attempt this challenge, assume you will be hacked. It's not a matter of if, it is a matter of when and how.
A strong understanding of security on the web should be possessed if you are going down this route. Knowledge of hashing functions, encryption, SSL and TLS, Sessions, and much more is essential.
I recommend using Express as a server, passport and passport-local, and helmet for some added security.
My Recommendations
The definitive guide to form-based authentication
These OWASP cheat sheets should also help
Wrapping things up
My #1 recommendations for Auth are Authpack and DID.app. They both are extremely well-thought-out services that are quite useful within their categories.
I hope you enjoyed this article. I spend a lot of time writing it and I appreciate any feedback or suggestions. If you would like me to write an article about implementing any of these services, please let me know.
Thank you for reading, and remember, hash your passwords!
Updates
I just discovered Magic. It is a link-based password-less authentication service. It might be worth consideration.
Top comments (12)
I don't understand the whole security auth discussions, not talking specifically about your post, looks like a good overall picture of the alternatives, I talk about the fact that I haven't found any place to dig deeper, go beyond recommendations or overall pictures.
The arguments for new tech in this topic are "just because..", "because is newer" or "because everyone know is like that", and in one hand everyone tells you, don't reuse passwords for multiple sites and a few commas later they talk about "Social Login". I often hear about how some auth methods are insecure because they rely on TSL, so is anyone considering a service without TSL?! or TSL have been broken?, that's a big deal!, way bigger than some random user being impersonated.
I haven't find a source that tells why some tech is weak and weak from what, even basic auth, what's the problem with basic auth?, of course it requires TSL, but you'll have TSL anyway, if not, who cares about the brand of locks you have if you leave your windows open?. And call me paranoid but why would I trust in some company running some non FOSS, non-audited and centralized code? is not the first rule not putting all the eggs in the same basket?.
I honestly don't understand, in this topic I've heard so many mix messages, contradictory statements, unstained claims and hearsay.
Even though there aren't any blatant problems with traditional authentication, there are some areas that can be improved. Often times, these are less focused on improving security and rather on providing an enhanced user experience. But when these attempts boost both security and the user experience, and they are effective cost-wise, then they are a good solution.
For example password-less authentication enhances the user experience greatly, and with an improvement on security. A random key is way more secure than any eight character password or even a 16 character password.
I understand that there's nothing wrong with the standard, but trying to improve the standard is how innovation forms. Even if these aren't good enough alternatives, eventually something that blows traditional auth out of the water will come.
I do agree with the lack of a deeper investigation into these standards. I might attempt something similar in the future, using this as my base to work off of
so in practice how does it works for the user in the password-less authentication? with an intermediary? we are talking about OAuth or alike? is there a way to make it stand-alone? and also what are the pitfalls of having more complex passwords/ransom keys if you limit the attempts or delay them?, because we are not talking about offline encryption nor how the passwords are stored in the DB, those are encrypted with the application keys.
For DID.app specifically, they are implementing OpenId Connect which is an identity layer, on top of OAuth2. As for in practice, DID.app sort of has a demo, when hit you "Get Started".
It is all a very seamless experience. I'm sure if you have concerns with them storing the logins, that you could build your own password-less solution using this protocol.
And because of the way password-less works, I don't think rating limiting would be an issue. The code for me to sign in was valid for 15 minutes and was 28 characters within a char-set of 52 (uppercase and lowercase letters). The possible combinations within that keyspace is
1.1171040382915234e+48. You'd need over a trillion guesses a second to crack that code.oh no, I misspoke, I meant, what is the problem of passwords being shorter if you can limit the number of requests in your API, so what if a password lives in a smaller random space if, as a malicious attacker you can only check 1 each second?, the goal is not to have more possible permutation, the goal is that it takes a long time, having a lot of permutations is the only choice for offline encryption because you can't control how fast an attacker can check, but with a live system you can, you just need to restrict the attempts, in number of tries or time between them.
I also wonder why or if I should force users to have certain degree of security, why can't a user be able to have an unsafe passwords?, if it will only affect themselves I think is their choice, not mine. Now, if that user could affect others, like someone with an admin permissions, of course, you may want to force them, but what if I don't care about my emails or YT, why should I be forced to have a long password, are Google gonna check if I have my passwords in post-its in my monitor?, check that I haven't give them to anyone? why should they care?.
Sorry about the pestering, maybe my questions need it's own discussion post. :)
It's okay. I think that there is nothing wrong with password security, and brute-force protection works very well. But, random passwords are still more secure. Even though they aren't necessary currently, it is always helpful to be one step ahead.
Either way, the security isn't the main focus. It's just a benefit of using it. I think the main benefit of password-less authentication is a much improved user experience
Good post! I did a few projects with Auth0 and it saved a good amount of time, especially when I think about the bugfixing that I didn't have to do later, haha.
At the moment I'm looking into AWS Amplify, which offers authentication based on AWS Cognito.
Thanks
DID is something very interesting. Thanks for writing.
Thank you, that was a good read. I wasn't aware of password-less authentication. Does that link in with 2FA at all or is it exclusively an alternative to normal password authentication?
I can recommend the keycloak if your app works in private network (or you have to integrate with ldap or other user manager system)