作为Passport的开发人员，花了我两分钱。
在开发Passport之前，我评估了Everyauth并确定它不符合我的要求。因此，我着手实施一个不同的解决方案。我要解决的主要问题是：
惯用Node.js
Everyauth广泛使用了Promise，而不是Node使用回调和闭包的方法。承诺是异步编程的另一种方法。虽然在某些高级情况下很有用，但我对将身份验证库强制应用到我的应用程序上并不满意。
此外，我发现正确使用回调和闭包会产生简洁，结构良好（几乎功能样式）的代码。Node本身的大部分功能都来自这一事实，Passport也照此进行。
模块化的
Passport采用一种策略设计模式来定义核心模块和各种身份验证机制之间明确的关注点分离。这具有许多好处，包括较小的整体代码大小以及定义良好且可测试的接口。
对于基本说明，请比较running
$ npm install passport和的区别
$ npm installeveryauth。Passport使您可以仅使用实际需要的依赖项来编写应用程序。
这种模块化体系结构已证明自身具有适应性，可以促进社区实现对各种身份验证机制的支持，包括OpenID，OAuth，BrowserID，SAML等。
灵活
Passport 只是中间件 ，使用
fn(req, res, next)Connect和Express建立的约定。
这意味着您 不会感到意外
，因为您定义了要在哪里路由以及何时使用身份验证。也没有对特定框架的依赖。人们已经成功地将Passport与其他框架（例如Flatiron）一起使用
相反，everyauth中的任何模块都可以将路由插入到您的应用程序中。这会增加调试难度，因为不清楚如何分配路由并导致与特定框架的紧密耦合。
Passport还以完全传统的方式出错，仅次于Express定义的错误处理中间件。
相比之下，每个验证人都有自己的约定，这些约定不太适合问题空间，从而导致长期存在的开放性问题，例如＃36
API认证
任何身份验证库的最大成就是其能够像基于Web的登录一样优雅地处理API身份验证。
在这一点上，我不会详细说明。但是，我鼓励人们研究Passport的同级项目OAuthorize和OAuth2orize。使用这些项目，您可以为基于HTML
/会话的Web应用程序和API客户端实施“全栈”身份验证。
可靠
最后，身份验证是应用程序的重要组成部分，您想完全依赖于它。每个验证人都有很多问题，但随着时间的流逝，其中许多问题仍然存在。在我看来，这是由于单元测试覆盖率低而导致的，这本身表明在每个认证中的内部接口均未适当定义。
相反，Passport的界面及其策略是定义明确的，并且被单元测试广泛涵盖。
针对Passport提出的问题通常主要是次要功能请求，而不是与身份验证有关的错误。
尽管这是一个较年轻的项目，但这种质量水平表明它是一种更成熟的解决方案，易于维护和信任。
