身份验证(Passport)足以保证Node js后端服务器的安全性？

使用Facebook身份验证的PassportJS是否足以支持使用Node JS的iOS后端？

当事情变得繁忙时,我还有toobusy包以拒绝请求(我猜这对DDOS来说会有好处).

我正在考虑使用nginx作为我的Node.JS服务器的反向代理.

还有哪些可以扩展的安全措施？一些建议和提示？任何安全相关的我应该关注PassportJS的认证会话无法处理？

在一篇文章中填写所有与安全相关的最佳实践有点困难,但是对于它的价值,这是我对这个问题的看法.

提供身份验证和保护它是两个独立的事情.PassportJS将能够处理与身份验证相关的所有事情,但这是完全不同的事情,防止它被愚弄或不堪重负.

将PasswordJS置于反向代理(RP)之后的一个(大)原因是,您将能够为与HTTP相关的任何内容提供第一道防线:标题/正文长度/数据,允许的方法,重复/不需要的标题,等等

Nginx/Apache/HAProxy都提供了出色的工具来处理这些情况,从最好的方面来说,你也可以很好地分离关注点:让反向代理处理安全性并让PassportJS处理身份验证.在架构方面,它也会更有意义,因为您将能够隐藏PassportJS节点的数量和基础架构.基本上,您希望将其显示为您的客户只有一个入口点.使用此架构,扩展也将更容易.与往常一样,确保您的RP保持尽可能少的状态,最好是没有状态,以便线性扩展.

为了正确配置您的RP,您需要真正了解PassportJS的协议(如果您想提供比Facebook更多的身份验证方法)的工作方式.知道了这一点,您可以将RP设置为:

拒绝任何不允许的请求HTTP方法(TRACE,OPTION,PUT,DELETE等).

拒绝大于已知大小的请求/标头/有效负载.

对PassportJS节点进行负载平衡.

在负载平衡方面要注意的一件事是粘性会话.一些验证器将其所有状态存储在加密的cookie中,其他验证器将是一个简单的会话句柄,只有创建会话的节点才能理解它.因此,除非您为后一种类型启用了会话共享(如果您需要PassportJS弹性),您需要配置RP以处理粘性会话.这应该是他们应该处理的最大状态量.如果您需要重新启动RP,这甚至可以正常配置.

正如你孜孜不倦地指出的那样,toobusy(或等效的)应该用来处理节流.根据我的经验,HAProxy在节流方面比其他RP更容易使用,但也toobusy应该正常工作,特别是如果你已经熟悉它.

您可能控制或不控制的另一件事是网络分区.显然,RP需要可访问,但它们应该充当PassportJS节点的中继.如果可能,最佳做法是将您的身份验证节点放在与后端服务器不同的网络/ DMZ上,这样就无法通过RP直接访问它们.如果受到损害,它们不应该被用作后端/内部网络的垫脚石.