Should You Create Your Own Login/Password (i.e. Authn) System?
If you do, you’re really creating an identity system. In the 90s (and even in 2000s), we would think all we have to do is store usernames (or emails) and password hashes, and provide a way to login, logout and reset password. The situation was not helped by ASP.NET membership provider and similar frameworks which defaulted to creating a username/password DBs.
But the world is very grim for such basic systems. For one, accounts will be compromised. Microsoft published in December 2019 that 44 million of Azure AD accounts had a password that was leaked elsewhere. Users will use common passwords that are easy to guess. So you may need to build a mechanism to identify those and require a password reset, esp. if a leaked password is found elsewhere. Although this cause is being helped by browsers (e.g. Chrome, Edge) and OSes (e.g. iPhone) that inform users if they are using a credential leaked in the cyber underworld.
Organizations then need to add MFA, and integrate with various external systems to send text messages. Create software to generate codes and verify. That starts incurring costs, so often there are Authenticator app-based integrations needed. This is all good and fun for software engineers.
But even then there will be phishing attempts and other malicious activity that will cause account to be compromised. Companies like Google, Microsoft, Amazon, Facebook, Okta, and many others use ML solutions to detect if a fraudulent attempt is being made. It’s not perfect science (it’s AI), so there are false positives. Nonetheless, it is enormously useful.
Of course, you will then also need to integrate with biometrics and invest in some sort of WebAuthn implementation, which is vastly more phishing resistant than any other means we know of today.
Identity doesn’t stop here. Once all of this is done, and a user has authenticated, there is cookie and token theft. Those are much harder to detect (although there are some heuristic methods), and mitigate. And it’s almost impossible to prevent theft in practice. You’ll have to start thinking about token binding, i.e. if a token is stolen from a device, it becomes useless. Or that the user has moved very quickly from one location to another (i.e. impossible travel) and invalidate login based on that. If you just invalidate every time a user moves to a new location, then you risk user frustration and a higher drop off rate since most users (if not all) hate authenticating.
And all of this has to be maintained perpetually. This is not a theoretical discussion. I know this from personal experience working in Microsoft’s Identity division. Okta, Microsoft’s biggest competitor, has also pretty much built similar functionality. Likewise, Google and Facebook also have such functionality in their consumer identity systems (gmail.com, facebook.com, etc.). This is just today’s reality.
So, unless your primary business is building identity systems, or you are too large to not have your own proprietary identity system or have some very niche use cases, it’s best to just use one of the platforms built by these companies (or any other reputable company you find). Most of these platform provide a whole lot of customization and continue to innovate in this space.
When it comes to the complexity and challenge in the identity systems, this essay is just an overview. There’s a lot more to identity. That’s why established companies and organizations like Subway, Irish MyGovID, New Zealand Ministry of Education and many others use Azure AD B2C. I know about customers of Azure AD B2C simply because I worked there are a lot, but there are similarly established businesses using Google Firebase, Amazon Cognito, Okta and others.