alt Hacker NewsThis 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.
Replies
Can you explain what you mean by “separate users from an ‘org’ or ‘team’ entity)?
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.