Item — HN Reader

Oh man, it really depends(tm). If you are building a small internal app, sure, but you'd often still be better off leveraging a social provider or employee directory.

I work in the auth space (for FusionAuth) and we run into plenty of folks that started out rolling auth themselves. Just username and password right? A bit of hashing, salting and leveraging a built-in crypto library.

But then you need to add account recovery. And then MFA. And then registration. And then progressive registration. And then webhook integration. And then passkeys. And then SAML integration. And the delegated SAML setup. And then and then and then.

You're distracted from your core application by feature requests for your login system.

You have lots of options nowadays. Use a library provided by your framework (Rails, Spring, and Django have them), use a tool like Better Auth, use a third party system like FusionAuth or Auth0. But don't build undifferentiated functionality that impacts your user experience.

PS Of course, where I stand depends on where I sit, but I firmly believe that you should not build an auth system the same way you should not build a database.

2 comments

I work at Clerk - same opinion here. Rolling your own auth is a trap. It's super easy when you are just getting started with your product and I cannot count how many times I have seen developers boast about how they rolled their own auth and now they aren't "locked in" to a vendor and are saving tons of money etc.

But the truth is, if you scale up as a company, it will end up costing you more in engineering salaries to re-create and maintain all the auth features you will need to support like @mooreds mentioned above than just using an auth library/vendor in the first place. And if you don't scale up, you are unlikely to push outside of the cheap or free tiers of any auth vendor you do go with, so it's a wash. Every reputable auth vendor has a pretty generous free tier.

It feels scary to go this direction because what happens if you blow up and then it becomes ultra expensive and now you're "locked in". All the time I see developers put hundreds of thousands, or millions of MAU into an auth vendor's pricing calc then gawk over the projected monthly bill and decide to roll their own. But the reality is that this doesn't happen. By the time you have that many MAU, you're typically paying out many multiples of that in engineer salaries alone, and paying an auth vendor a fraction of a single engineer's salary to handle your auth is substantially better value than hiring a team to build and maintain your own from scratch.

We have churned our fair share of large company customers over the years, as has every other auth vendor. They have all been because they needed feature we didn't have, not because the price was too high.

This is kinda like the ORM vs no-ORM argument. I think that off-the-shelf auth will accelerate your development for sure (like an ORM) but eventually, you are going to feel constrained by the framework/tool you are using. You will need to work around it. You will find that using it 'correctly' results in poor performance, and so you deviate here and there. Pretty soon you tell yourself, "man I should have just used SQL" or "man, I should have just rolled my own auth". At least ~20 years of software dev has taught me this.

For an MVP or a prototype, I think it's okay to use an off-the-shelf tool. For something serious that will have long-term legs, I would do it myself. I hear all of your concerns and arguments and agree there are a lot of footguns. But again, having spent the better part of my adult life using and interfacing with these tools, I have an innate understanding of how to model auth correctly (separate it from the user, separate users from an 'org' or 'team' entity, etc).

You said it though, 'it depends' is really the right answer here.

That's a great analogy. My only addition would be the nuance of that data modelling is way more flexible than authentication (and this is said as someone who is continually surprised by the business requirements, standards, and complexities of auth). Data modelling, after all, needs to handle the entirety of reality (at least what can be mapped to a computer). So you're more likely to outgrow it.

I've heard plenty of stories of folks moving from homegrown auth to a off-the-shelf solution, but that's because I'm in the off-the-shelf auth space.

It'd be super interesting to hear stories of folks who went the other way, and outgrew their service provider's auth.

Can you explain what you mean by “separate users from an ‘org’ or ‘team’ entity)?

You are building your app with a single user in mind. They can create <thing> (blog posts, photo albums, code repositories, you name it). Eventually you realize, sometimes people are working in teams or groups. Multiple people need to have access to <thing>. So instead of architecting from the get-go that a <thing> is owned by a user (usually with some kind of FK, like an owner_id, or user_id) you want to start by having an abstraction there right out the gate. Things are owned by a team or org, and a user belongs to an org.

This is why a lot of SaaS you use these days will come with a "default project" or "default team" that might just be 1:1 with your own person. But injecting that abstraction layer makes it super easy down to the road to allow other individuals to join or participate in the management of those entities.