by Animesh - Jan 24, 2024
It seems the internet gets upset at the idea of rolling your own auth code. I get it, it is a complex problem, and there are many well written authentication providers out there.
I was even delving into a few of them yesterday. I was flabbergasted to see how large these repos are. For instance, at the time of writing
Not to mention, these services need to be run as a separate service, they need their own datastore, and will need some upkeep and monitoring. Unfortunately, the pricing models of all auth providers seem prohibitively expensive for b2c apps with simple needs, so using their cloud offering is out of the question.
I feel the needs for Chips of Fury are simple. We don't want the whole kitchen sink of authN and authZ features. So let's see...
Logins are optional. So the app would continue to work with anonymous users like it does now. I do not want to change that.
Verified email addresses would be the unique identifier for a user. Oauth providers should usually provide info on whether the email is verified or not. This should help in making sure that a user who initially logs in via Google, can later login using email magic links into the same account. And vice versa. Apple allows anonymizing emails, so I'm not sure how useful it will be for Apple users. But if an Apple user has shared their original email, then the above flow would work for them as well.
Some issues might happen in email delivery for magic links / OTPs, but having three options to login should give a fairly high coverage in case something does go wrong.
It is surely non-trivial, but I think it will be in the order of magnitude of thousands of LOC. If my guess is right, and I have a good understanding of what I'm doing, it might just be better to hand roll the auth code.
So off I go to read about Oauth2. This book looks nice. I'll post on how this goes.