There is a belief in the tech industry that you should avoid building your own authentication/sign-in services for applications you make. This is for a very valid reason, many people don't understand how to properly create a service that secures their application and can safely store user data. You see it all the time: massive breaches of an online company's databases that contain plaintext passwords, or engineers speaking about log files containing private user information. However, learning to properly manage such a system becomes invaluable when working on projects and applying to jobs.
I created my first OAuth system in early 2019 using PHP; probably not the language choice most people would pick, but that's the one I chose because I had been using it for years prior. I found an OAuth 2.0 system that was open sourced and designed for PHP and MySQL. I was using PHP and PostgreSQL, but it was an easy enough swap. I spent the time learning the functions, architecture, and flow of user data to fully understand how this OAuth system was being created. After a couple of hours of sketching it out and programming, I had created my first OAuth 2.0 system. I rolled it out to all my existing projects online and moved away from session based security. I was happy that I had learned this new authentication method, but I assumed from that point on I was going to be using off-the-shelf libraries for exactly what I had done (but at least I understood the underlying mechanics now!).
Just 2 short months later, I had just gotten a job at a company that was building on-top of their old Adobe Cold Fusion web app. The existing code base used session based security, as it was the thing to do with server side languages like CF, but now they wanted to introduce more modern technologies like Spring and Angular into the stack. They needed a way to authenticate their over 600,000 existing users with a new authentication system that was stateless. That is when I mentioned my previous experience building OAuth 2.0 compliant systems, and they sent me off to work on a central authentication service that would later become the glue that held our stack together. After just 1 week, I had built a service that connected all of our new modern technologies into our legacy stack without having to retrofit any code into the impossibly large pre-existing system. That service still runs to this day, generates over 1 million JWEs (encrypted JWTs) per week for their users, and connects iOS, Android, Angular, React, Bash, Spring, Cold Fusion and .NET developments together. After completing that project, I thought "Okay, this is cool, but surely it won't come up again, right?". Boy, was I wrong.
Fast forward just about one year from when I developed that central authentication service for that software company; I was now somewhat of a local university celebrity because my friend and I were making a dating app for our school. I elected to make my stack include React Native (to make iOS/Android cross-platform development easier) and Spring Boot, with the occasional sprinkle of a PHP script here and there for extra measure. I did not have the money to pay another service to handle my authentication, nor would I want to spend what measly budget we had on something as foolish as that. We needed posters, stickers, valentine's day cards, donut giveaways, and advertising to be done; not an authentication service. So I took the plunge, and did the thing that everyone tells you not to do; I built my own authentication service for an app I was releasing in production. I am writing this now 2 years after this event, and we have fixed a lot of bugs and have made a tonne of updates to the app, but that authentication service has never been a cause for concern. It has been rock solid and has become my template for building all other authentication services.
Since the release of the dating app, I have reused that Spring Boot authentication codebase I designed in well over 15 applications. I have recreated it in Python, PHP (again), Node.JS, Web3, and end up going back to it at least once a month for new projects. It is scary to design your own authentication service, you really don't want to screw it up; but the experience you gain from learning the methodologies behind designing strong and secure authentication services will always come up in the tech world. Take your time, do the research, and try your hand at building your own OAuth 2.0 service. You might be surprised with how simple it is to do it correctly.