This should be exhibit number one why you should always favor open source libraries rather than writing your own plumbing functionality, especially around authentication and authorization. The onus should be on the developer to explain why the open source library isn't a fit, rather than defaulting to 'roll your own'.
The edge cases discussed don't pop up that often unless you have lots of folks using your software or are really diligent about fuzzing and testing edge cases. If you roll your own, say, username system, you probably aren't going to fall into either of those two cases. Which means you're vulnerable.
but then again, open source does not mean its good software, obviously. there should be some way quickly check if a library meets security best-practices. like a some sort of "vetted software" reference
Also, using a 3rd party library for something as important as authentication because you don't know how it works doesn't sound much better nor secure.
Like storing sensitive data in the authn's session system because you don't understand encryption vs signing nor how to find out -- maybe it's time to just sit down and credentialize as a craftsman.
The authn/z systems I've used that were the biggest headaches in my life were kitchen sink frameworks trying to generalize over everyone's creature features, and they were often tied to a company/community culture of not-gonna-touch-it that only hurt users and security.
I think you should absolutely understand any third party systems/libraries you use, especially when it is as important as authentication. Using a third party component doesn't free you up to be lazy or to use it incorrectly.
My comment was stating that you should default to these types of libraries and only roll your own if you can't do what you need to, simply because they're more likely to handle edge cases that can have serious implications.
Do you do unicode normalization on your usernames? I freely admin that I don't, and wasn't aware it was needed until I read this post.
If you don't fall into any of the affected cases, what exactly is the vulnerability? The security aspect I get, and happen to agree with 100%, but if I roll my own sub-optimal username classification system for my CRUD app that gets 80 users in its entire lifetime, so what? I will have certainly learned a lot more than just typical `npm install usernames`.
Actually, the first step in a lot of Django projects is to rip out the default config and ditch usernames in favor of email addresses for login, and attach some form of unique internal id to the "account" (or whatever billing, social IDs, etc. might be associated with).
The edge cases discussed don't pop up that often unless you have lots of folks using your software or are really diligent about fuzzing and testing edge cases. If you roll your own, say, username system, you probably aren't going to fall into either of those two cases. Which means you're vulnerable.