I think you're assuming that scratch coding is slower than integrating an OSS you don't know. When I was thinking about this for one project, it came close enough that I rolled my own basic auth system according to the NIST recommendations and it definitely took less time than integrating something that I didn't know (and accepting all the unknown bugs that are inevitably there).
I also don't buy the argument "don't waste time on something that is not a differentiator" - I'm going to spend time on it anyway, so I might as well spend the time in the most productive way possible. Also, I guarantee that your solution isn't bug-free, and eventually one of them is going to bite me, so that also factors into the decision about time.
The basic version of authentication is actually really simple. When you add SSO, RBAC, Oauth2, ACLs, and other stuff, it gets really complicated. People should make intelligent decisions about what they want to do here rather than just using a provider.
> I think you're assuming that scratch coding is slower than integrating an OSS you don't know.
I think that depends on all kinds of factors (domain knowledge, docs of the library, etc). I think learning one or two auth libraries or frameworks will be useful to most devs, as they can re-use that knowledge repeatedly. But I get your point, sometimes rolling your own can be quicker. (And it is certainly more fun to code something up than to read up on integration docs.)
However, I think you're dismissing the long term maintainability advantages you get from using a focused library or auth server.
When a request comes in for a feature (let's change the hashing algorithm and factor of our passwords to meet new NIST standards, let's add login with LinkedIn, can we integrate using SAML), if you have the right library or auth server, it's often a configuration parameter, as opposed to code.
When there's a security issue, someone clearly owns it and has an incentive to fix it as fast as possible. Some auth servers (FusionAuth among them) pay people regularly to penetration test the system. Is that something you are going to do with your homegrown auth system?
That said, I'm glad you found a solution that works for you. Different strokes for different folks, as they say.
I also don't buy the argument "don't waste time on something that is not a differentiator" - I'm going to spend time on it anyway, so I might as well spend the time in the most productive way possible. Also, I guarantee that your solution isn't bug-free, and eventually one of them is going to bite me, so that also factors into the decision about time.
The basic version of authentication is actually really simple. When you add SSO, RBAC, Oauth2, ACLs, and other stuff, it gets really complicated. People should make intelligent decisions about what they want to do here rather than just using a provider.