2 node.js 微服务之间的身份验证策略
Authentication strategy between 2 node.js microservices
我打算做一个简单的管理CP。我是老派 PHP 开发人员，通常所有内容都在一个巨大的单体服务器中，微服务的概念不适用。
在我的下一个应用程序中，我希望有：
Express UI（前端）<----> REST/GraphQL API <-----> 数据库服务器
想法是尽可能限制对数据库的访问。来自用户的所有请求将仅转到前端，并且 API 将仅由我的解决方案中的其他服务器在内部使用。
我将在 API 和 DB 之间设置 IP 过滤器，并且很可能在 Frontend 和 API 之间设置 IP 过滤器。但我担心的是 - 假设我想要一个管理员来创建一个产品。虽然此用户将在前端使用会话进行身份验证，但我需要对 API 的请求也进行某种程度的身份验证。现在忽略 IP 过滤器，不希望任何人能够向 API.
发送 REST 请求
我有几个想法，请大家给我意见：
使用 mongodb 在 API 和前端之间共享快速会话（可能在另一台服务器上）- 我发现延迟问题
将 API 服务与前端放在同一台服务器上并使用 Redis 共享会话 - 有点违背微服务分离的目的
登录时，为任何用户操作生成始终在前端和 API 之间转发的 jsonwebtoken - cookie 窃取将是一个问题，因为我只能验证用户登录，而不是那个他授权执行某些操作
登录时，将私钥发送给管理员并让他签署所有转发给 API 的请求 - 这看起来像 CPU 矫枉过正
是否缺少任何常用的解决方案？将前端和 API 中间人分开是矫枉过正，还是一种好的做法？我可以轻松地合并 2 并直接从前端与 DB 对话，然后我可以像 PHP.
一样通过会话管理所有内容
感谢您的任何意见！干杯
(1) 的更精细的实现是使用 session 服务器。这个想法是纯粹消除数据库查找延迟，而不是一般 session 查找的瓶颈。它充当缓存层。零编码实现是使用 redis 或内存缓存之类的东西作为 session 存储。
但一般来说，像 JWT 这样的加密签名机制的可扩展性要高得多，因为它涉及零 I/O 查找。您所做的就是验证令牌是否已正确签名。只要您保证应用程序的机密安全，您就是安全的。您甚至可以直接在令牌中对用户角色和权限等内容进行编码，以完全避免为它查询数据库。
JWT 的关键思想是所有的安全都隐藏在后端。 front-end 仅将令牌回传给服务器作为身份验证证明。
但是由于front-end存储了令牌，它可以被javascript劫持。一种解决方案是使用 HttpOnly cookie 作为传输令牌的机制。我什至看到过在 Authorization header 中发送令牌的主要部分但在 HttpOnly cookie 中发送签名的实现。这会阻止脚本读取整个令牌。
我打算做一个简单的管理CP。我是老派 PHP 开发人员，通常所有内容都在一个巨大的单体服务器中，微服务的概念不适用。
在我的下一个应用程序中，我希望有：
Express UI（前端）<----> REST/GraphQL API <-----> 数据库服务器
想法是尽可能限制对数据库的访问。来自用户的所有请求将仅转到前端，并且 API 将仅由我的解决方案中的其他服务器在内部使用。
我将在 API 和 DB 之间设置 IP 过滤器，并且很可能在 Frontend 和 API 之间设置 IP 过滤器。但我担心的是 - 假设我想要一个管理员来创建一个产品。虽然此用户将在前端使用会话进行身份验证，但我需要对 API 的请求也进行某种程度的身份验证。现在忽略 IP 过滤器，不希望任何人能够向 API.
发送 REST 请求我有几个想法，请大家给我意见：
使用 mongodb 在 API 和前端之间共享快速会话（可能在另一台服务器上）- 我发现延迟问题
将 API 服务与前端放在同一台服务器上并使用 Redis 共享会话 - 有点违背微服务分离的目的
登录时，为任何用户操作生成始终在前端和 API 之间转发的 jsonwebtoken - cookie 窃取将是一个问题，因为我只能验证用户登录，而不是那个他授权执行某些操作
登录时，将私钥发送给管理员并让他签署所有转发给 API 的请求 - 这看起来像 CPU 矫枉过正
是否缺少任何常用的解决方案？将前端和 API 中间人分开是矫枉过正，还是一种好的做法？我可以轻松地合并 2 并直接从前端与 DB 对话，然后我可以像 PHP.
一样通过会话管理所有内容感谢您的任何意见！干杯
(1) 的更精细的实现是使用 session 服务器。这个想法是纯粹消除数据库查找延迟，而不是一般 session 查找的瓶颈。它充当缓存层。零编码实现是使用 redis 或内存缓存之类的东西作为 session 存储。
但一般来说，像 JWT 这样的加密签名机制的可扩展性要高得多，因为它涉及零 I/O 查找。您所做的就是验证令牌是否已正确签名。只要您保证应用程序的机密安全，您就是安全的。您甚至可以直接在令牌中对用户角色和权限等内容进行编码，以完全避免为它查询数据库。
JWT 的关键思想是所有的安全都隐藏在后端。 front-end 仅将令牌回传给服务器作为身份验证证明。
但是由于front-end存储了令牌，它可以被javascript劫持。一种解决方案是使用 HttpOnly cookie 作为传输令牌的机制。我什至看到过在 Authorization header 中发送令牌的主要部分但在 HttpOnly cookie 中发送签名的实现。这会阻止脚本读取整个令牌。