Authentication 用微服务实现公共API密钥

对于大多数客户端应用程序和UI方法，JWT似乎是一种携带基于OAuth方法的令牌的好方法。这允许用户/身份验证服务与实际访问的服务分离

鉴于这种架构

我的问题是：在公共API（即Github或Slack）中，使用特定角色生成承载密钥。如何在微服务架构中授权该密钥？这些类型的密钥是否只需要在每个请求中查询Auth服务

---

API网关可以缓解这种情况吗？我想了解是否存在服务间通信最少的解决方案。谢谢大家!

通常，这是使用作用域解决的。作用域是授予用户执行某些操作的权限，例如，将有一个用于读取存储库的作用域，另一个用于更新存储库，另一个用于删除存储库等

这些作用域绑定到令牌，通常由用户自己请求或根据用户类型自动添加。与身份验证过程相同，它们可以包含在jwt中编码为声明的令牌本身中，或者可以在请求一个操作时通过调用oauth服务器来请求或检查它们

将它们包含在jwt中的优点是，无需在每次请求操作时调用外部服务器，因此延迟较低，所需带宽较少，并且可以消除故障点。显然，如果使用此解决方案，则必须对令牌进行正确签名甚至加密，以避免可能的操作。

---

然而，它也有缺点，最危险的是令牌不能被撤销，因为该信息不能包含在令牌中，并且检查令牌是否有效的服务只能访问令牌本身中包含的数据。因此，这类令牌通常会有一点到期时间，因此在令牌被盗的情况下，其有效性将非常有限

因此，您是否建议给定一组作用域，根据给定的作用域生成一个小型结构化密钥（但不是JWT），是否传播到相关服务，并且只有这些服务才能授权密钥？我了解jwt在大多数情况下是如何受益的，但我感兴趣的是了解第三方令牌是如何实际授权的-它们接触哪些服务否，如果范围在令牌中编码为jwt内的声明，则接收令牌的服务可以检查该令牌是否有效以执行请求的操作。另一方面，如果令牌不是jwt（不透明令牌），那么服务必须调用发出该令牌的oauth服务器来检查作用域，并用它们确保操作是否正确，我理解jwt部分，它更干净。但听起来，对于第三方应用程序访问的API键（如Slack API或类似的东西），由于它们是不透明的，因此无法避免攻击Auth服务。