Notes on DIY Authentication
Why implementing authentication ourselves may not be so simple.
“Authentication (AuthN) is the process of verifying that an individual, entity, or website is who or what it claims to be by determining the validity of one or more authenticators (like passwords, fingerprints, or security tokens) that are used to back up this claim”.
In the 1990s, it was common for each application to store and manage its own user identities. There is no official naming that I know of, though “DIY” seems to be a good fit. I would not be surprised to also hear the terms “in-house” or “homegrown” authentication.
Although this can be a simple solution, it comes with some costs. An enterprise with ten applications, for example, would have to manage the identity of the same user ten times. The same is true for the user, who needs to have ten different identities and credentials.
Another downside of homegrown solutions is that the application itself would not only have to directly receive the user’s credentials, it would also go through the heavy burden of ensuring password strength rules, managing sessions, guarding itself against replay attacks, dealing with password reset flows, and so on.
The issue of having duplicated identities was solved by LDAP, which centralises them and allows multiple services within the same data centre to authenticate the identities of their users in a single place.
This new solution, however, was also not perfect. LDAP is built to work for services within the same data centre. For applications outside of it, or that belong to a different organisation, this presented itself as a solid limitation.
Other strategies came by, such as SAML 2.0, that allows for SSO across different domains. And then, as with everything in engineering, SAML itself was also faced with limitations, which were solved by subsequent standards such as OpenID Connect (OIDC) for authentication and OAuth 2.0 for authorization.
Is this all to say that you should not handle authentication and authorisation within your application? Not at all, but consider first whether you intend to achieve enterprise-level users, whether you wish to be SOC2-compliant and whether you want to deal with the burden of managing the security alongside at the same place that you already manage your business rules.