passport.js 的微服务身份验证架构
Microservices authentication architecture with passport.js
我正在编写一个玩具应用程序，用于在 nodejs (expressjs) 上练习微服务和身份验证。
我有一个 React 客户端、一个身份验证服务和其他服务（到目前为止它们只响应 "Hi"）。
- 客户端将托管在 CDN 中。
- auth服务监听5000端口（举例）
- 其余服务侦听端口 6000-6100。
- 我有一个 redis 数据库来存储会话信息（twitter 提供的 oauth 令牌）。
- A mongodb 存储应用程序信息的位置（与此问题无关）。
想法是，未经身份验证的客户端通过单击 Twitter 按钮 (SSO) 进入身份验证服务。然后 auth 服务获取生成的 twitter oath 令牌，并将此令牌设置在 redis 存储中。然后其余服务可以访问令牌，因此他们通过检查请求是否已存在于 redis 存储中来了解请求是否已通过身份验证（如果用户删除其帐户，它也将从 redis 存储中删除） .
一旦通过身份验证，我就在客户端和服务器之间来回发送 Twitter 令牌。
我发现这种方法非常简单（其他人使用 nginx 代理进行身份验证，但我认为没有理由这样做，除非服务托管在不同的域中，但我不太了解）所以我'我担心我遗漏了一些安全方面的东西。
问题：
- 这种做法正确吗？
- 共享 Twitter 令牌是否安全（我认为是）？
- 这里有没有我没有注意到的安全问题？
使用这种方法，您将必须在所有服务中验证令牌，如果您对此没有问题，那么您可能没问题。
Twitter 访问令牌可能有过期时间，因此必须使用刷新令牌从身份验证服务获取新的访问令牌：
- 当访问令牌过期时，您将 return 从您尝试与之通信的服务 X 向客户端发送 401。
- 客户端必须调用提供刷新令牌的 Auth 服务，获取新的访问令牌
- 最后，客户端将使用这个新的访问令牌再次访问服务 X，对其进行验证并从服务 X 获得预期的响应。
在我最近的任务中，我编写了一个代理所有令牌的微服务，使用这种方法我的代理处理了从身份验证到角色的所有事情，并为过期令牌发送 401 和撤销刷新令牌等。我认为这给了我一个更大程度的关注点分离。
重要说明：在上面的刷新令牌场景中，我的代理只会经历 invalid/expired 访问令牌的负载，而在您的场景中，任何服务都可以通过无效访问代币...
另一种方法是让 Service-A 和 Service-B 调用 auth 服务来验证令牌，但这会导致服务之间的流量增加很多，因为每个带有令牌的 HTTP 请求都必须经过验证.在这种情况下，无效的令牌请求也会到达您的服务 X 并因此推断它有一些负载...
我正在编写一个玩具应用程序，用于在 nodejs (expressjs) 上练习微服务和身份验证。
我有一个 React 客户端、一个身份验证服务和其他服务（到目前为止它们只响应 "Hi"）。
- 客户端将托管在 CDN 中。
- auth服务监听5000端口（举例）
- 其余服务侦听端口 6000-6100。
- 我有一个 redis 数据库来存储会话信息（twitter 提供的 oauth 令牌）。
- A mongodb 存储应用程序信息的位置（与此问题无关）。
想法是，未经身份验证的客户端通过单击 Twitter 按钮 (SSO) 进入身份验证服务。然后 auth 服务获取生成的 twitter oath 令牌，并将此令牌设置在 redis 存储中。然后其余服务可以访问令牌，因此他们通过检查请求是否已存在于 redis 存储中来了解请求是否已通过身份验证（如果用户删除其帐户，它也将从 redis 存储中删除） . 一旦通过身份验证，我就在客户端和服务器之间来回发送 Twitter 令牌。
我发现这种方法非常简单（其他人使用 nginx 代理进行身份验证，但我认为没有理由这样做，除非服务托管在不同的域中，但我不太了解）所以我'我担心我遗漏了一些安全方面的东西。
问题：
- 这种做法正确吗？
- 共享 Twitter 令牌是否安全（我认为是）？
- 这里有没有我没有注意到的安全问题？
使用这种方法，您将必须在所有服务中验证令牌，如果您对此没有问题，那么您可能没问题。
Twitter 访问令牌可能有过期时间，因此必须使用刷新令牌从身份验证服务获取新的访问令牌：
- 当访问令牌过期时，您将 return 从您尝试与之通信的服务 X 向客户端发送 401。
- 客户端必须调用提供刷新令牌的 Auth 服务，获取新的访问令牌
- 最后，客户端将使用这个新的访问令牌再次访问服务 X，对其进行验证并从服务 X 获得预期的响应。
在我最近的任务中，我编写了一个代理所有令牌的微服务，使用这种方法我的代理处理了从身份验证到角色的所有事情，并为过期令牌发送 401 和撤销刷新令牌等。我认为这给了我一个更大程度的关注点分离。
重要说明：在上面的刷新令牌场景中，我的代理只会经历 invalid/expired 访问令牌的负载，而在您的场景中，任何服务都可以通过无效访问代币...
另一种方法是让 Service-A 和 Service-B 调用 auth 服务来验证令牌，但这会导致服务之间的流量增加很多，因为每个带有令牌的 HTTP 请求都必须经过验证.在这种情况下，无效的令牌请求也会到达您的服务 X 并因此推断它有一些负载...