I wrestled with Passport for 3 weekends last October on my side project before reverting to a simple form for login. Passport has several dependencies that aren't well-documented, like a SQL ORM. It took a full weekend of researching to figure out what ORMs were and how they were used, since almost every blog assumes readers will recognize one in their code. This led to blogs pushing the opinion that ORMs were pointless and useless unless you already knew SQL.
Then, there are articles like the Hackernoon post explaining why most Passport blog posts are wrong in one way or another.[0] This article explains that there are no "copy/paste" authentication solutions for Javascript, as there are for other languages - and Passport is probably the best out there.
As there's no "copy/paste" auth solution for Javascript, it becomes essential to understand how auth works with your site. It has to be added to every Express render call, to work with the Session. And rolling your own is educational - you can learn some of the common pitfalls and why rolling your own is a bad idea.
I do plan to go back to Passport sometime this year. The number of Oauth providers is nearly overwhelming - too much to ignore. But also daunting for the first-time student.
Passport is pretty large so it can be confusing. IMO, it's much easier to not use the session stuff in passport and just do your own thing letting passport handle the flow. You can use the BasicAuth strategy on a /login url to sign someone in and grant a token, and then use Bearer auth strategy to check the token on the rest of your urls.
Doing it that way, Passport doesn't require an ORM at all. You'll need to obviously provide a way to auth a user and verify a token, but that's then up to you.
Now, if you want to actually use OAuth it can get complicated because the flow.
"Rolling your own crypto" usually refers to constructing new cryptographic schemes out of either primitives or just out of wholecloth.
Using well-developed hashing schemes like pbkdf2 (which the auth snippet uses) or bcrypt (another good and common option) and storing the output is not rolling your own crypto. Writing your own hash function would be rolling your own crypto.
People talk about not rolling your own crypto because crypto is very, very sensitive to even very small errors, in ways that other code is not. Writing your own authentication using a well-known strong hashing scheme (which handles salting and verifying passwords in a timing attack resistant way) is much less likely to have vulnerabilities that aren't obvious.
I think that if you use passportjs because you don't understand how to implement authn yourself, then you're no any better off from a security standpoint.
To me, passportjs might be useful if you need to plug into 3rd party auth APIs, but I don't really see the point. Authentication is a core part of your application and you should always know exactly how it works.
If you can't store an authn secret with confidence, how can you do anything with confidence?
I would disagree on the grounds that authentication is, generally speaking, a well-solved problem for the level most applications require. It's a better use of your time to use a library that's well-used and well-understood rather than rolling Yet Another (Probably Bad) Authentication Framework.
I will concede, however, that the most basic forms of authentication that I've used are so close to the metal that they're usually already built into whatever you're using to do communication.
