微服务架构中的JWT身份验证

Question

问题

质疑如何在微服务应用程序中创建身份验证服务，并让其他服务检查该令牌（JWT）并检索用户？

可能的解决方案

我目前的想法是基于auth服务在用户通过身份验证后将{ token, user }插入Redis。所有其他服务都可以在Redis中检查用户的Authorization: Bearer kdI8$dj$nD&...标头令牌。

• 如果Redis中存在token，则会对用户进行身份验证。
• 如果Redis中不存在token，则用户未经过身份验证。

1. 用户将{ username, password }发送至身份验证服务
2. Auth服务验证凭据并检索{ token, user }
3. Auth服务将{ token, user }插入Redis
4. 用户Service-1
向{ token }发出请求
5. Service-1在Redis中找到{ token }并检索{ token, user }
6. Service-1执行此操作并发送回{ data }

这种方法是否存在任何可能的安全性，逻辑或架构问题？

Answer 1

为什么你想在Redis中存储令牌并不是很清楚。安全令牌通常包含有关用户（声明数据）的信息。如果您需要有关未存储在令牌中的用户的信息，您应该能够通过对用户ID声明的简单数据库查询来查找。

每个服务都可以通过检查其digital signature（仅需要签名证书的公钥），生命周期（令牌何时到期），受众（谁是令牌）等来验证传入令牌？ 。如果呼叫者提供有效令牌，则用户已通过身份验证。

Answer 2

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

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

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

在我的recent assignment中，我编写了一个代理验证其令牌的所有请求的微服务，代理处理从login / auth到角色的所有内容，并为过期的令牌发送401，并撤销刷新令牌等。我认为这样与在所有服务中处理令牌相比，让我更加分离了顾虑。然而，它当然使得代理成为系统的一个可能的瓶颈，auth服务的自动缩放意味着在我的情况下处理这个。

此外，我没有使用redis，但在accessstoken中存储了一个哈希键（由散列的accessstoken属性+ salt组成），我可以通过重新调整accesstoken + salt的其他属性来验证。

重要提示：在上面的刷新令牌场景中，我的代理只会遇到无效/过期的accessstoken加载，而在您的方案中，任何服务都可以通过无效令牌到达，我不知道如果您在特定情况下有任何疑虑，但可能值得一提......

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