Well... you're not supposed to roll your own cryptography. Like, don't go thinking that you're going to do better than a NIST contest winner if you need a cryptographic primitive.
That goes for protocols as well.
And security-related "build vs. buy" decisions should always include an element of battle-testing. If you have the option to pick an off-the-shelf TLS library rather than implementing your own, both are gonna be full of bugs but at least the former will have already had CVEs filed and fixed. (That's not, btw, an assumption that one likes to write buggy code, but rather, a choice to operate under the assumption that one can always be surprised. Schneier's Law and all).
That said, there comes a point to model your own problem domain, and make sure that your product includes features and components that allow it to meet your information security goals.
I think software engineering has done itself a bit of a disservice by making security seem "scary" (and therefore, something to avoid at all costs) rather than a necessary and boring component of any computer system.
P.S. If anybody wants resources, I'm a big fan of the way that FIPS-199 -> FIPS-200 -> SP 800-53
breaks down security goals, impact levels, and appropriate control measures. You can pick a goal, assess your impact level, and pick something off-the-shelf pretty quickly.
Using something third party isn’t free - even for zero monetary cost there’s integration cost, documentation, support, and maintenance uncertainty.
The choice between rolling your own and third party is already a trade-off. The future uncertainty around third party services without a clear business just tips the scales, it’s not the whole justification.
why not instead fork repo just in case but still use better auth until proven wrong? In case they go evil you just build from you forked one. At that point you would still have to either maintain your own auth or better auth fork.
With current AI your agents probably still will be better with maintaining a fork. Auth libs have pretty limited API surfaces comparing to e.g. ui frameworks.
I prefer to maintain my code, tailored for my need, than maintaining a massive library that has support for every authentication method there is, while trying to be as generic as possible and fit every business.
but to me that’s less risk than our auth getting bought by somebody whose business goals don’t necessarily align with mine.