Implementing correctly an authentication system is hard.
If you start creating your website/application now, please use a third party authentication. Third party authentication can be social login (e.g. the ubiquitous Login with Facebook button) or identity management tools like Auth0 or Okta.
It's not just about storing username/password in the database. In a standard web application, an authentication system needs to:
- store password hash instead of password in cleartext. And each user should have their own salt. And the hash function should be expensive to compute. For all this, you would need a very good understanding on Rainbow tables, Bcrypt, Hash algorithms and salts.
- have email verification and reset-password features. For that you might need to generate and store a temporary, short-lived token that is used to activate an account or to reset password. And this is the simple part. Making sure that your email doesn't fall into the Spam folder is much harder.
On the front-end side, the app needs to have a decent UI: a login form that at least validates the email and password, a sign-up form, a reset-password form. Not to mention modern authentication expects support for MFA and soon (hopefully) WebAuthn.
More importantly, your users don't want to go through a lengthy registration process and create yet another username/password. Without a proper password manager (which probably 99% users don't use), they tend to reuse the same password which is bad in terms of security!
So why choosing the hard path and face the risk of password leaks, database hackings and above all, inferior user experience? Of course some applications need to have their own authentication system (banking app is an example but that's also changing with PSD2) but they are rather minority.
So which 3rd-party verification should my app use?
This really depends on your app. If getting user's Facebook feed can be a big plus to your app, then you should probably go with Login with Facebook. If having access to user's Twitter feed is valuable, then Login with Twitter is more appropriate. If your app only requires user basic information like email, name, avatar picture then I would suggest Login with SimpleLogin, a developer-friendly login solution. Disclaimer: I happen to be SimpleLogin co-founder so this advice is obviously subjective đ .
We should all stop requiring users to choose a username and password. There are better alternatives.
Please let username/password rest in peace â°ïž.
Top comments (6)
Agreed - a balance needs to be struck. If you happen to be using a library that does all the hard stuff with authentication for you, it's a lot easier... but it's still on YOU to secure the database, among other things. Letting someone else handle the heavy lifting when you're not up to the task yourself is DEFINITELY a good idea - whatever provider you use.
Absolutely agree! Time should be better spent on the core feature and not the repetitive boring login code.
Because we don't want authentication to be outsourced to third party, side projects are fine with vendor locks, but a large business will always stay away from Vendor Lock. And authentication is a core of any business, one always wants to have full control. And yes we hate proxy, when financials transactions are involved, a business transaction is processed, proxy is dangerous.
Youâre right that most of big business would want to have their own authentication system, mostly because they have ressources (developers) to maintain and evolve it. Most of them do support other Identity Provider though so this is a bit hybrid mode in this case I guess.
Vendor lock is almost inevitable one way or another (except if you are Google đ ) so this should be taken with a grain of salt IMO.
toO lAtE
git.varelus.com/kami/mc-oauth
but i'd love some constructive criticism
There are hundreds (if not thousands) Identity provider and I have the impression Mc-oauth is one of them :). Apple recently entered the group as well so I guess itâs never too late đ