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.

The data lives in your server, everything is yours, if that happens, you just fork or write your own. Not sure what writing yourself first buys here.

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.