Many applications start with rudimentary authentication systems. It might just be a table of users in your database, with hashed and salted passwords and a simple exchange of a valid password for a token or session. This is simple, and many web apps have worked like this for a long time—even now. As your application grows in complexity and user base size, you might find that your old DIY auth system isn’t quite meeting your product’s ever-changing needs. This is where Authentication Providers and Authentication-as-a-Service come in.
In this article, you will see the various types of authentication systems available to you. You will learn some advantages and limitations of each type, as well as which ones might suit your application and its needs. Ultimately, this will come down to your product requirements and what you expect from your authentication system. The good news is that due to the diverse range of offerings, no matter what level of feature completeness you are looking for, there will almost certainly be something that ticks all the boxes.
The first and probably most common type of authentication system is the DIY approach. There isn’t any strict standard here, as it comes down to whatever works for you. As mentioned above, a popular choice is storing user records in a database with hashed and salted passwords. This is a pretty standard approach. While it can be easy enough to implement, and many frameworks and libraries provide drop-in solutions for this kind of authentication system, there are some noteworthy drawbacks.