您如何处理微服务中的授权和身份验证？

Question

在我的公司，我们正在微服务之上构建一个应用程序。我们正在努力决定如何处理授权和身份验证。我们正在考虑使用 OpenId Connect 来验证用户身份，但在授权方面，我们需要一些建议。

让我解释一下解决方案的工作原理：一个用户可以在不同的部门拥有不同的角色，部门的数量可以超过 200 个。在每个部门中，用户可以有多个角色。我们了解处理角色的推荐方式是将它们放在从客户端发送到服务器（JWT）的令牌中。但是，我们担心这会使令牌负载过大。据我所知，浏览器最多可以保存 5KB 的数据头。在我们的例子中，这意味着大约 50 个部门有两个角色（未压缩）。这样做的好处是用户在他/她进入微服务时被授权和验证。正如我所提到的，缺点是令牌中的大负载。

我们也在寻找一个不同的选项，我们将 JWT 保持在最低限度（用户 ID 和部门 ID），并在每个请求上查询 Keycloak 的用户权限（可能添加一些寿命很短的缓存机制）。这种方式会向授权服务器产生大量请求。

我正在寻找其他人如何解决此问题的一些建议/经验。如果需要，我很乐意提供更多信息。

为方便您提出建议，以下是对两种选择的简短说明： 1）使用JWT来处理认证和授权？为什么？ 2）保持JWT轻量级并向每个微服务中的授权服务器发出请求？为什么？

Answer 1

我会说，两种选择：

选项 1

1. 保持 JWT 灯亮
2. 将 OAuth2“授权码”授权类型与刷新令牌和访问令牌一起使用
3. 使用 LFU 等驱逐策略将用户权限缓存在集中式分布式缓存系统中
4. 在访问令牌更新期间（根据访问令牌有效期定期发生），获取用户最新的访问权限并刷新缓存
5. 如果缓存中没有访问权限，请查询 Keycloak 并将条目添加到缓存中

因此，

1. 权利的任何变化都会在令牌有效期内得到体现
2. 由于缓存，性能会更好

选项 2

与选项 1 相同，只是您可以在用户权限 DB 上使用更改数据捕获 (CDC) 来保持缓存随访问权限的任何更改而更新。