I'm surprised to see so many top comments here promoting building your own auth. For years I've only heard "never roll your own auth."
I'm surprised to see so many top comments here promoting building your own auth. For years I've only heard "never roll your own auth."
I think it's a correction, There's multiple levels of interpretation:
1. Don't roll your own crypto
2. Don't roll your own auth strategy
3. Don't Roll your own auth code
4. Don't host your own auth infrastructure.
For the last few years level 4 has been aggressively pushed with a lot of advertising spend to push people towards prohibitively expensive hosted providers. Donning a tinfoil hat for a moment, auth as a service companies have made everything seem substantially more difficult than it is too for simple needs.
Now we're seeing a correction back to 2 and 3 as people way up the risks of SaaS vs just using a easier to manage local library and discovering it's not as scary as it's been made out to be if you follow now fairly well established patterns.
the providers aren't going anywhere, people still need them for a variety of reasons but their time as the default is ending and whether this is good is to be determined.
It’s likely because the quick thought is that auth is just user table with hashed password.
Then when you really start thinking about it, the list of requirements grows.
Of course it’s still totally doable for an average developer, but takes time and mistakes can be catastrophic. And maybe the time is better spent developing stuff that differentiates you from others.
There are few hard and fast rules, but "never use something that could change as a primary key" and "never roll your own Auth" will always be true