使用passport.js的微服务认证架构

Question

我正在写一个玩具应用程序，用于在nodejs（expressjs）上练习微服务和身份验证。

我有一个反应客户端，一个身份验证服务和其他服务（他们只是回复＆＃34;嗨＆＃34;到目前为止）。

• 客户端将托管在CDN中。
• auth服务侦听端口5000（例如）
• 其余服务侦听端口6000-6100。
• 我有一个redis数据库来存储会话信息（由twitter提供的oauth令牌）。
• 存储应用程序信息的mongodb（与此问题无关）。

这个想法是未经身份验证的客户端通过单击Twitter按钮（SSO）进入身份验证服务。然后，auth服务获取生成的twitter誓言令牌，并在redis存储中设置此令牌。然后，其他服务可以访问该令牌，以便通过检查请求是否已经存在于redis存储中来知道它是否已经过身份验证（如果用户删除了其帐户，它也将从redis存储中删除） 。 经过身份验证后，我会将Twitter令牌从客户端来回发送。

我发现这种方法非常简单（其他人使用nginx代理进行身份验证，但我认为没有理由，除非服务托管在不同的域中，但我不太了解它）所以我＆＃ 39;我很担心我错过了一些关于安全的事情。例如。

问题：

1. 这种做法是否正确？
2. 分享推特令牌是否安全（我想是这样）？
3. 我在这里没有注意到任何安全问题吗？

Answer 1

使用这种方法，您必须在所有服务中验证令牌，如果您对此可以，那么您可能没问题。

Twitter访问令牌的过期时间可能需要使用刷新令牌从auth服务获取新的访问令牌：

• 当访问令牌过期时，您将从您尝试与之通话的服务X返回401到客户端。
• 客户端必须调用Auth服务提供刷新令牌，获取新的访问令牌
  • 最终，客户端将使用此新访问令牌再次访问Service X，对其进行验证并从Service X获得预期的响应。

在我的recent assignment中，我编写了一个代理所有令牌的微服务，使用这种方法，我的代理处理从auth到角色的所有内容，并为过期的令牌发送401，并撤销刷新令牌等。我认为这给了我更多的关注点分离。

重要说明：在上面的刷新令牌场景中，我的代理只会遇到无效/过期的accessstoken的加载，而在您的方案中，任何服务都可以使用无效的令牌来达到......

另一种方法是让Service-A和Service-B调用auth服务来验证令牌，但这会推断服务之间的更多流量，因为每个带有令牌的HTTP请求都必须经过验证。在这种情况下，无效的令牌请求也会到达您的服务X，从而推断出一些负载......