我赢了't elaborate much on this point. However, I encourage people to look into Passport' s兄弟项目，OAuthorize和OAuth2orize . 使用这些项目，您可以为基于HTML /会话的Web应用程序和API客户端实现"full-stack"身份验证 .
根据我的经验，Everyauth没有't work out of the box with it'的密码登录风格 . 我正在使用express3而且我声明我的中间件就像 app.use(everyauth.middleware(app)); 那样它仍然没有'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去尝试护照 .
16
这回答有点晚，但我发现这个帖子（听到所有关于Everyauth的负面反馈后）决定使用Passport ......然后讨厌它 . 它是不透明的，只能用作中间件（例如，你无法从GraphQL endpoints 进行身份验证），并且我遇到了多个难以调试的bug（例如How do I have two Express sessions?） .
7 回答
与我的两分钱一起，作为Passport的开发者 .
在开发Passport之前，我评估了everyauth，并确定它不符合我的要求 . 所以，我开始着手实施一个不同的解决方案 . 我想要解决的主要问题是：
Idiomatic Node.js
everyauth广泛使用promises，而不是Node的使用回调和闭包的方法 . Promise是异步编程的另一种方法 . 虽然在某些高级情况下很有用，但我对我的应用程序强制执行此选择的身份验证库感到不舒服 .
此外，我发现正确使用回调和闭包可以产生简洁，结构良好（几乎是功能样式）的代码 . Node本身的大部分功能来自于这一事实，而Passport也是如此 .
Modular
Passport采用策略设计模式来定义核心模块与各种认证机制之间关注点的明确分离 . 这有许多好处，包括较小的整体代码大小以及定义良好且可测试的接口 .
有关基本示例，请比较运行
$ npm install passport和$ npm install everyauth之间的差异 . Passport允许您仅使用实际需要的依赖项来创建应用程序 .这种模块化架构已经证明自身具有适应性，促进了一个社区已经实现了对各种身份验证机制的支持，包括OpenID，OAuth，BrowserID，SAML等 .
Flexible
Passport只是中间件，使用Connect和Express Build 的
fn(req, res, next)约定 .这意味着没有任何意外，因为您可以定义路径的位置以及何时使用身份验证 . 特定框架也没有依赖关系 . 人们成功地将Passport与其他框架一起使用，例如Flatiron
相比之下，everyauth中的任何模块都可以将路径插入到您的应用程序中 . 这可能使调试变得困难，因为如何调度路由并导致与特定框架的紧密耦合是不明显的 .
Passport也是一种完全传统的错误，接下来是Express所定义的中间件 .
相比之下，everyauth有自己的约定，这些约定不能很好地适应问题空间，导致长期存在的问题，如#36
API Authentication
任何身份验证库的最高成就是它能够像基于Web的登录一样优雅地处理API身份验证 .
我赢了't elaborate much on this point. However, I encourage people to look into Passport' s兄弟项目，OAuthorize和OAuth2orize . 使用这些项目，您可以为基于HTML /会话的Web应用程序和API客户端实现"full-stack"身份验证 .
Reliable
最后，身份验证是应用程序的关键组件，您希望完全依赖它 . 每个人都有很长的issues清单，其中许多都会随着时间的推移而保持开放和重新出现 . 在我看来，这是由于单元测试覆盖率低，这本身表明每个内部接口都没有适当定义 .
相比之下，Passport的接口及其策略定义明确，并且单元测试广泛涵盖 . 针对Passport提交的Issues往往主要是次要功能请求，而不是与身份验证相关的错误 .
尽管是一个年轻的项目，但这种质量水平表明了一种更成熟的解决方案，更容易维护和信任 .
护照
模块化和透明
好文档
社区贡献（由于它的模块化）
适用于每个人和他们的狗（再次，由于它的模块化）
Everyauth
发展历史悠久，成熟 .
不再维护
伟大的文档
适用于各种服务
刚完成从Everyauth到护照的转换 . 原因如下 .
Everyauth不够稳定 . 最后一个问题是上周我被一个神秘的问题所困扰，其中facebook身份验证可以在local.host和 生产环境 环境中运行，但不是在myoku的测试环境中，即使使用相同的代码和数据库以及新的heroku应用程序实例 . 那时我没有关于如何隔离问题的理论，因此删除Everyauth是合乎逻辑的下一步步 .
它使用用户名/密码凭据提供标准身份验证支持的方式不易与单页面Web应用程序方法集成 .
我无法让Everyauth使用Google帐户 .
每个人的积极发展似乎在下降 .
该港口令人惊讶地无痛，只需要几个小时，包括手动测试 .
显然，我建议去护照 .
我先尝试过Everyauth，然后去了Passport . 这让我更加灵活，特别是 . if（例如）我需要不同提供商的不同逻辑 . 它还使（imo）配置自定义身份验证策略变得更容易 . 另一方面，它没有视图助手，如果这些对您很重要 .
我过去常常使用Everyauth mongoose-auth . 我发现很难在不拆除everyauth模块的情况下正确拆分我的文件 . 在我看来，Passport是一种创建登录的更简洁的方法 . 有一篇文章我觉得很有帮助http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/
请注意这篇文章的日期，它将表明这篇文章的相关性 .
根据我的经验，Everyauth没有't work out of the box with it'的密码登录风格 . 我正在使用express3而且我声明我的中间件就像
app.use(everyauth.middleware(app));那样它仍然没有'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去尝试护照 .这回答有点晚，但我发现这个帖子（听到所有关于Everyauth的负面反馈后）决定使用Passport ......然后讨厌它 . 它是不透明的，只能用作中间件（例如，你无法从GraphQL endpoints 进行身份验证），并且我遇到了多个难以调试的bug（例如How do I have two Express sessions?） .
所以我去寻找并找到了https://github.com/jed/authom . 根据我的需要，这是一个更好的图书馆！它只有一条线，所以它真的没什么大不了的 .
更重要的是，它的设计为您提供了更多的控制，使您可以轻松地按照自己的方式实现授权，而不是Passport的方式 . 此外，与Passport相比，它更简单，更容易学习 .