身份validation（Passport）足够安全与Node js后端服务器？
使用Facebook身份validation的PassportJS足够用于带有Node JS的iOS后端吗？
我也有toobusy包，当事情变得很忙的时候，也会拒绝请求（我猜这对DDOS来说是好事）。
我正在考虑使用nginx作为我的Node.JS服务器的反向代理。
什么是更多可以扩展的安全措施？ 一些build议和提示？ 任何与安全相关的问题，我应该关注PassportJS的身份validation会话无法处理？
在一篇文章中塞入所有与安全有关的最佳实践是有点困难的，但是为了什么是值得的，这里是我对这个问题的看法。
提供身份validation和保护是两件不同的事情。 PassportJS将能够处理与身份validation相关的所有事情，但这是一个完全不同的事情，防止被愚弄或不知所措。
将PasswordJS置于反向代理（RP）之后的一个（很大的原因）是，您将能够为与HTTP相关的任何事情提供第一道防线：头部/体长/数据，允许的方法，重复/不需要的头部，等等
Nginx / Apache / HAProxy都提供了很好的工具来处理这些情况，而且还可以很好地分离问题：让反向代理处理安全性并让PassportJS处理authentication。 架构方面，它也会更有意义，因为您可以隐藏PassportJS节点的数量和基础结构。 基本上，你想让它看起来像你的客户只有一个切入点。 这个架构的扩展也会更容易。 与往常一样，确保您的RP（s）保持尽可能less的状态，最好没有，以便线性缩放。
为了正确地configuration您的RP，您需要真正了解PassportJS的协议（如果您想提供更多的身份validation方法，而不仅仅是Facebook）的工作方式。 知道这一点，你可以设置您的RP（s）来：
- 拒绝任何不允许的请求HTTP方法（TRACE，OPTION，PUT，DELETE等）。
- 拒绝大于已知大小的请求/标头/有效载荷。
- 负载平衡你的PassportJS节点。
有一点需要注意的是负载均衡是粘性会话 。 一些authentication者把他们所有的状态存储在一个encryption的cookie中，其他的将是一个简单的会话句柄，只有创build会话的节点才能理解。 因此，除非您为后一种types启用会话共享（如果您需要PassportJS弹性），则需要configurationRP以处理粘滞会话。 这应该是他们应该处理的状态的最大数量。 configuration正确，如果您需要重新启动RP，甚至可能工作。
正如你勤勉地指出的那样，应该有适当的toobusy （或者相当的）来处理节stream。 根据我的经验，HAProxy比其他RP在调节方面稍微容易一些，但是toobusy应该可以正常工作，特别是如果你已经熟悉了。
另一件可能或不可能控制的事情是networking分区。 显然，RP需要可访问，但是它们应该作为PassportJS节点的中继。 如果可能的话，最好的做法是将身份validation节点放置在与后端服务器不同的networking/ DMZ上，以使其不能通过RP直接访问。 如果妥协，他们不应该被用来作为后台/内部networking的垫脚石。
根据Passport文档：“支持使用用户名和密码，Facebook，Twitter等authentication”。
它是中间件，通过它可以将多种安全方法与NodeJS集成在一起。
您应该考虑应用程序的目的，是否只支持Facebook身份validation或自定义注册/login过程。 如果是提供第二种select，那么在这种情况下，最好不要依赖任何社交网站，如Facebook / Twitter或任何其他的authentication。
更好的select是创build自己的令牌，如JWT令牌，并将其与来自多个平台的用户绑定。 它将帮助您扩展项目的范围，以整合其他社交网站。
以下是将JWT集成到NodeJS中的链接。
https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens
同样，市场上还有许多其他的博客和教程可以将JWT与NodeJS集成在一起