Everyauth和Passport.js似乎有着非常相似的功能集。 什么是一些二，这将使我想用一个比其他的正面和负面的比较？
Answer 1:
钟声在我的两分钱，作为开发商护照 。
发展护照之前，我评估everyauth，并确定它不符合我的要求。 于是，我开始着手实施不同的解决方案，它会的。 我想解决的重大要点是：
成语的Node.js
everyauth广泛使用的承诺，而不是使用回调和关闭的节点的做法。 承诺是一种替代方法，以异步编程。 虽然在一些高层次的情况下非常有用，我是不舒服的认证库强迫在我的应用这个选择。
此外，我发现，正确使用回调和封闭的产生简洁，良好架构的（几乎是实用的风格）代码。 许多节点本身的力量来自于这个事实，并且护照跟风。
模块化
护照采用的策略设计模式来定义的核心模块和各种认证机制之间的关注点的明确分离。 这样做有很多好处，包括更小的总体代码大小和明确的和可测试的接口。
对于基本的说明，比较运行之间的差别$ npm install passport和$ npm install everyauth 。 护照，您只需使用你真正需要的依赖手艺您的应用程序。
这种模块化的架构已经证明了自己适应能力强，有利于已经实施了各种各样的认证机制，包括OpenID的，OAuth的，BROWSERID，SAML等支持社区
灵活
护照只是中间件 ，使用fn(req, res, next)的连接并快速建立规则。
这意味着， 没有惊喜 ，因为您可以定义你希望你的路线，当你想使用身份验证。 也有在特定的框架没有依赖关系。 人们成功地使用Passport与其他框架，如熨斗
相反，在everyauth任何模块可以插入路由到您的应用程序。 这可以使调试困难的，因为它是非显而易见的一条路由是怎么将分赴并导致紧耦合与特定的框架。
护照还的方式，完全是传统的错误，下ING到错误处理中间件快报定义。
相比之下，everyauth有它自己的约定，不符合的问题以及空间，造成长期未解决的问题，如＃36
API认证
任何身份验证库的最大成就是它能够处理API认证的优雅作为基于网络的登录能力。
我不会在这一点上阐述了。 不过，我鼓励人们寻找到护照的兄弟项目， OAuthorize和OAuth2orize 。 通过这些项目，可以实现“堆满”认证，为HTML /基于会话的Web应用程序和API客户端。
可靠
最后，认证是一个应用程序的重要组成部分，和一个你想成为完全舒适的依靠。 everyauth有一长串问题，其中许多保持开放及铺设一段时间。 我认为，这是由于低的单元测试覆盖率，这本身表明在everyauth内部接口没有适当地定义。
相比之下，护照的接口和它的策略是明确和单元测试覆盖广泛。 问题对护照申请往往大多是次要的功能要求，而不是与认证错误。
尽管是一个年轻的项目，这个质量水平提出了更成熟的解决方案更易于维护和的信任。
Answer 2:
护照
- 模块化和透明
- 良好的文档
- 社区贡献（由于它的模块化）
- 大家一起和他们的狗作品（再次，由于它的模块化）
Everyauth
- 漫长的发展历史，技术成熟。
- 不再保留
- 伟大的文档
- 具有广泛的服务工作
Answer 3:
刚刚结束的由everyauth改为护照。 究其原因，以下。
- Everyauth不够稳定。 上周我被一个神秘的问题咬伤的最后一根稻草是哪里Facebook验证将在local.host并在生产环境中在Heroku我的测试环境中工作，但没有，即使有相同的代码和数据库以及新的Heroku应用实例。 在这一点上我跑出来的理论为如何找出问题，以便消除everyauth是合乎逻辑的下一步。
- 它提供了使用用户名/密码凭据标准认证支持的方式不能简单的用一个单页web应用程序的方式整合。
- 我是无法得到everyauth与谷歌帐户的工作。
- everyauth的积极发展似乎在下降。
端口出人意料地无痛，只是采取了几个小时，包括手动测试。
所以很明显，我建议去办理护照。
Answer 4:
我第一次尝试了Everyauth既然已经去护照有。 这让我觉得有点更灵活，ESP。 如果（举例来说）需要使用不同的提供不同的逻辑。 这也使得它更容易（IMO）配置自定义身份验证策略。 在另一方面，它不具备的视图助手，如果这些对你很重要。
Answer 5:
我用Everyauth更具体猫鼬-auth的。 我发现很难正确地分割了我的文件，而无需拆卸everyauth模块。 护照在我看来是一个用于创建登录清洁方法。 还有，我发现非常有用写了http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/
Answer 6:
这回答有点晚了，但我发现这个线程和（听到所有关于Everyauth负反馈后）决定使用护照...然后恨它。 它是不透明的，只有担任中间件（你不能从GraphQL端点验证，例如），和我打了不止一个难于调试错误（例如， 如何做，我有两个快速会话？ ）。
所以我去寻找和发现https://github.com/jed/authom 。 对于我的需求，这是一个更好的图书馆！ 这是一个有点水平低于其他两个库，所以你必须做的事情一样把用户到会话自己...但是这只有一行所以真的没什么大不了的。
更重要的是它的设计为您提供了更大的控制权，因此很容易实现您的授权，你所希望的方式，而不是护照意的方式。 另外，相比于护照这是一个非常简单并且更容易学习。
Answer 7:
请注意，此文章的日期，就会显示这个职位的相关程度。
根据我的经验，Everyauth没有盒子的制定与它的密码登陆风格。 我使用express3和我宣布我的中间件，像这样app.use(everyauth.middleware(app)); 它仍然没有在everyauth本地传递给我的模板。 最后git的承诺是一年前，我估计新的软件包已经打破everyauth。 现在，我要去尝试护照。
文章来源: Everyauth vs Passport.js?
