Chiming in with my two cents, as the developer of Passport.
Before developing Passport, I evaluated everyauth and determined that it didn't meet my requirements. So, I set about implementing a different solution which would. The major points I wanted to address are:
Idiomatic Node.js
everyauth makes extensive use of promises, instead of Node's approach of using callbacks and closures. Promises are an alternative approach to async programming. While useful in some high-level situations, I wasn't comfortable with an authentication library forcing this choice upon my application.
Furthermore, I find that proper use of callbacks and closures yields concise, well architected (almost functional style) code. Much of the power of Node itself comes from this fact, and Passport follows suit.
Modular
Passport employs a strategy design pattern to define a clear separation of concerns between the core module and various authentication mechanisms. This has a number of benefits, including smaller overall code size and well defined and testable interfaces.
For a basic illustration, compare the difference between running $ npm install passport and $ npm install everyauth. Passport lets you craft your application using only the dependencies you actually need.
This modular architecture has proven itself adaptable, facilitating a community that has implemented support for a wide variety of authentication mechanisms, including OpenID, OAuth, BrowserID, SAML, etc.
Flexible
Passport is just middleware, using the fn(req, res, next) convention established by Connect and Express.
This means that there are no surprises, as you define where you want your routes and when you want to use authentication. There are also no dependencies on a specific framework. People are successfully using Passport with other frameworks such as Flatiron
In contrast, any module in everyauth can insert routes into your application. This can make debugging difficult, as it is non-obvious how a route will be dispatched and leads to tight coupling with a specific framework.
Passport also errors in a way that is entirely conventional, next-ing to error-handling middleware as defined by Express.
In contrast, everyauth has its own conventions, which don't fit the problem space well, causing long-standing open issues such as #36
API Authentication
The crowning achievement of any authentication library is its ability to handle API authentication as elegantly as web-based sign on.
I won't elaborate much on this point. However, I encourage people to look into Passport's sibling projects, OAuthorize and OAuth2orize. Using these projects, you can implement "full-stack" authentication, for both HTML/session-based web apps and API clients.
Reliable
Finally, authentication is a critical component of an application, and one you want to be fully comfortable relying on. everyauth has a long list of issues many of which remain open and resurface over time. In my opinion, this is due to low unit test coverage, which itself suggests that the internal interfaces in everyauth are not suitably defined.
In contrast, Passport's interfaces and its strategies are well-defined and extensively covered by unit tests. Issues filed against Passport tend to mostly be minor feature requests, rather than bugs relating to authentication.
Despite being a younger project, this level of quality suggests a more mature solution that is easier to maintain and trust going forward.
