Absolutely disagree. You shouldn't roll your own bcrypt, but you should have full knowledge of how it's used to offer authentication. Hell this is required to even move forward with sales in many enterprise software contexts. If you don't know how passwords work, for the love of god don't offer password-based login.
Exactly. It is not the implementation of the auth module that matters to me so much as is the API through which it slots into the rest of the system. I want the expert designed modules that I can plug various systems into.
Because we haven’t seen good frameworks at the user management level, I think, the mistakes made by the creators of that YT video are common in the industry.
Please make your substantive points thoughtfully and without personal attacks. "The fuck you are talking about" is much too aggressive for this site, as you'll see if you'll review the guidelines.
Even "I'm sorry but" is the sort of flamebait we're trying to avoid here.
Not implementing auth doesn't mean using platforms. Just use any of the many OIDC client/server libraries or completely pre-made open source dockerized services.
For example react-oidc-context on the client side and Passport.js on the server, or Casdoor.
Verifying that your vendor hasn't done anything dumb is hard.
Supporting your customers when they have problems is hard.
Debugging issues with a thrird party in the loop is hard.
Just because you farmed out auth doesn't mean you get to stop monitoring for breaches, or doing all the other things you need to do to have an eye on security.
Farming out auth just ads a recurring cost per user and complexity that your going to ignore till its a bigger issue than dealing with this up front would have ever been.
