Everyauth vs Passport.js? [closed]

Question

Everyauth and Passport.js seem to have very similar feature sets. What are some of the positive and negative comparisons between the two that would make me want to use one over the other?

Confiscatory

Another alternative is to use Grant - that's only if you are looking for OAuth middleware. It supports hundreds of providers and it's configured via straightforward JSON data structure. – Spoliation

Answer 1

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.

Sundog

@Jared Hanson: Do you have any example of how to use passport with RESTfull auth? – Brinson

I don't see how promises really change the cited benefits of vanilla callback style. You're pretty much doing the same thing with less code in scenarios where a linear series of events trigger additional callbacks. – Bertie

Agree with @ErikReppen that promises are irrelevant in this comparison. – Kara

Ironically, but passport has much more issues now: github.com/jaredhanson/passport/issues (273 vs. 148 for everyauth). – Ferry

I am sorry but passport is very complicated. It has a terrible documentation. And still using things from the past (callback approach). And I am not even considering the lack of support (no issues resolved, no merged pr) – Rhetorical

Answer 2

Passport

• modular and transparent
• good docs
• community contributions (owing to it's modularity)
• works with everyone and their dog (again, owing to it's modularity)

Everyauth

• long development history, mature.
• no longer maintained
• great docs
• works with a wide range of services

Elderberry

Everyauth is no longer actively maintained. – Eada

@Eada thanks for letting me know. Answer has been updated – Elderberry

Heads up that Passport no longer seems to be maintained either. The last functional commit was made 2 years ago and there's 300 open issues. – Hollishollister

Answer 3

Just finished changing from everyauth to passport. The reasons were the following.

1. Everyauth is not stable enough. The final straw was last week I got bitten by a mysterious issue where facebook authentication would work on local.host and on the production environment, but not in my test environment on heroku, even with identical code and databases and a new heroku app instance. At that point I ran out of theories as to how to isolate the issue, so removing everyauth was the logical next step.
2. The way it provides support for standard authentication using username/password credentials is not easily integrated with a single page web app approach.
3. I was unable to get everyauth to work with Google accounts.
4. Active development of everyauth seems on the decline.

The port was surprisingly painless, only taking a few hours, including manual testing.

So obviously, I recommend going for passport.

Daube

Thank you for the true story although the final straw is not clear. – Viaticum

Answer 4

I tried out Everyauth first and have since gone to Passport. It struck me as somewhat more flexible, esp. if (for example) I need different logic for different providers. It also makes it easier (imo) to configure custom auth strategies. On the other hand, it doesn't have the view helpers, if those are important to you.

Swamper

I noticed that Passport.js says it splits concerns and I wonder if everyauth is built similarly. – Confiscatory

Answer 5

This answers a bit late, but I found this thread and (after hearing all of the negative feedback about Everyauth) decided to use Passport ... and then hated it. It was opaque, only worked as middleware (you couldn't authenticate from a GraphQL endpoint, for instance), and I hit more than one hard to debug bug (eg. How do I have two Express sessions?).

So I went looking and found https://github.com/jed/authom. For my needs this is a much better library! It's a bit lower-level than the other two libraries, so you have to do things like putting the user into the session yourself ... but that's only one line so it's really no big deal.

More importantly its design gives you a lot more control, making it easy to implement your authorization the way you want and not the way Passport intended. Plus, compared to Passport it's a lot simpler and easier to learn.

Borchers

Answer 6

I used to use Everyauth more specifically mongoose-auth. I found it hard to split up my files properly without dismantling the everyauth module. Passport in my opinion is a cleaner method for creating logins. There is a write up that I found very helpful http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/

Ovule

Answer 7

Note the date of this post, it will indicate how relevant this post is.

In my experience, Everyauth didn't work out of the box with it's password login style. I am using express3 and I declare my middleware like so app.use(everyauth.middleware(app)); and it still wasn't passing in the everyauth local to my template. The last git commit was a year ago and I figure new packages have broken everyauth. Now I'm going to try passport.

Barkentine