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

Question

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

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

我们还在寻找一个不同的选项，我们将JWT保持在最低限度（userid和departmentid），并在每个请求中查询Keycloak以获取用户权限（可能会添加一些具有较短生命周期的缓存机制）。这种方法会向授权服务器生成大量请求。

我正在寻找的是一些关于别人如何解决这个问题的建议/经验。如果需要，我很乐意提供更多信息。

为了便于您提供建议，以下是两种选择的简短描述：1）使用JWT处理身份验证和授权？为什么？ 2）保持JWT点亮并在每个微服务中向授权服务器发出请求？为什么？

Answer 1

我会说，有两种选择：

选项1

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

从而，

1. 权利的任何变更都将使令牌有效期得到反映
2. 由于缓存，性能会更好

选项2

与选项1相同，但您可以在用户权限数据库上使用更改数据捕获（CDC），以便在访问权限发生任何更改时更新缓存。