如何额外保护已使用 OAuth 2.0 访问令牌的 REST 服务？

Question

我有以下 REST 服务：

• 向外界公开的聚合器服务。它由用户 OAuth 2.0 访问令牌保护。此聚合器调用内部服务。
• 内部服务位于网络级别不暴露于外界。它还受到同一用户 OAuth 2.0 访问令牌的保护。访问令牌从聚合器传递到内部服务。

现在假设 Internal 服务意外地暴露给了外界。理论上，用户可以对不应该允许的Internal服务进行更改。

有没有办法额外保护Internal服务，以便用户无法访问它，即使它会意外暴露给他们？

同时使用机器对机器 (M2M) 令牌和用户令牌来保护内部服务是否可能或明智？

Answer 1

最正确的 OAuth 设计方法是使用范围和声明。这样做可以有效地允许访问令牌和用户身份在微服务之间流动，并提供正确的保护并且没有安全问题。最好通过一个例子来解释。

场景

考虑一个在线销售业务场景。客户端与订单服务交互，订单服务调用计费服务。客户端不调用计费服务，但用户发起的操作在那里执行。

访问代币流

OAuth 标准未定义范围的设计方式。通常它们是由架构师设计的，用于端到端的业务流程。此处显示了一个示例，其中每个 API 都会接收并验证每个请求的 JWT 访问令牌。请注意，有时客户端会发送不同的凭证，例如 cookie 或引用令牌，但这些凭证会被转换为 JWT 访问令牌，然后传递给 API。

用户身份从 Orders API 流向 Billing API。由于它使用 JWT 格式，因此它仍然是可验证和可审计的。这两个 API 都会以零信任的方式验证每个请求的 JWT。

API 还会检查所需的范围。在此示例中，我使每个微服务的范围相同，因为它们都覆盖相同的业务领域。计费 API 可能只允许此范围用于创建发票操作。如果访问令牌发送到任何其他计费端点或范围不足的任何其他 API，则会立即拒绝并显示 403 禁止响应。要创建发票，计费 API 可能会添加其他限制，例如检查有效负载是否包含可用于其他验证的订单 ID。

JWT 验证后，API 信任令牌中的声明并将其用于业务授权。这将根据用户身份、角色和其他值锁定用户可以执行的操作。因此，如果用户能够使用浏览器工具获取他们的 API 凭据并重放它，他们应该获得与在 UI 会话中获得的 API 完全相同的访问权限。

更高权限操作

这些API也会被其他用户和客户端使用，他们可能需要调用更高权限的操作。接下来考虑几个调用相同 API 的员工应用程序，这些应用程序也可能会暴露在互联网上。这些可能允许更高的权限并需要多重身份验证：

在这里，我还使用了分层作用域，这是设计对 API 端点的高级访问的一种可能的技术。如果销售应用程序的用户尝试调用高权限端点，订单和计费 API 都会立即返回 403。

其他选项

流动代币还有更高级的选项。例如，OAuth 令牌交换 可用于在调用上游 API 之前为同一用户获取不同的令牌。最常见的是，这用于为同一用户获取范围缩小的另一个令牌。

可以为上游 API 获取具有完全不同范围的令牌，但这样做通常会削弱安全性。执行此操作的解决方案通常使用客户端凭据流来获取具有诸如

billing

之类范围的令牌，然后在无法验证的标头中传递用户 ID。这可能会被利用。

单独的基础设施解决方案（例如计费 API 需要相互 TLS）也存在一些问题。它们锁定对所有客户端的访问，这不利于架构并且通常不是您想要的。在上面的示例中，它将阻止从财务应用程序进行访问。

总结

如果您需要一个代币，您建议的 2 个代币可能会作为一种短期战术解决方案。但作为未来的方向，目标是通过以最佳方式使用范围和声明来使用 OAuth 提供的零信任成分。