提问人：Harold L. Brown 提问时间：8/10/2023 更新时间：8/20/2023 访问量：97
如何额外保护已在使用 OAuth 2.0 访问令牌的 REST 服务？
How to additionally secure a REST service that is already using an OAuth 2.0 access token?
问：
我有以下REST服务：
- 向外界公开的聚合器服务。它由用户 OAuth 2.0 访问令牌保护。此聚合器调用内部服务。
- 内部服务位于网络级别，不向外界公开。它还由同一用户 OAuth 2.0 访问令牌保护。访问令牌从聚合器传递到内部服务。
现在，假设内部服务意外地暴露在外界。从理论上讲，用户可以对内部服务进行不应允许的更改。
有没有办法额外保护内部服务，以便用户无法访问它，即使它会意外暴露给他们？
是否可能或明智地同时使用机器对机器 （M2M） 令牌和用户令牌来保护内部服务？
答：
1赞
Gary Archer
8/11/2023
#1
最正确的 OAuth 设计方法是使用范围和声明。这样做可以有效地允许访问令牌和用户标识在微服务之间流动，并提供适当的保护，并且没有安全问题。最好用一个例子来解释。
场景
考虑一个在线销售业务场景。客户端与订单服务交互，订单服务调用计费服务。客户端不调用计费服务，但用户启动的操作会在那里执行。
访问令牌流
OAuth 标准未定义范围的设计方式。通常，它们由架构师设计，用于端到端业务流程。此处显示了一个示例，其中每个 API 在每个请求上接收并验证 JWT 访问令牌。请注意，有时客户端会发送不同的凭据，例如 cookie 或引用令牌，但这些凭据会转换为 JWT 访问令牌，这些令牌将交付给 API。
用户身份从 Orders API 流向 Billing API。它仍然是可验证和可审计的，因为它使用 JWT 格式。这两个 API 都以零信任方式在每个请求上验证 JWT。
API 还会检查所需的范围。在此示例中，我使每个微服务的范围相同，因为它们都涵盖相同的业务领域。计费 API 可能只允许此范围用于“创建发票”操作。如果将访问令牌发送到任何其他计费终结点或范围不足的任何其他 API，则会立即拒绝该令牌，并显示 403 禁止响应。要创建发票，Billing API 可能会添加其他限制，例如与有效负载中的订单 ID 检查相关的限制。
JWT 验证后，API 信任令牌中的声明，并将其用于业务授权。这将根据用户身份、角色和其他值锁定用户可以执行的操作。因此，如果用户能够使用浏览器工具提取其 API 凭据并使用 Postman 等工具重播它，则他们应该获得与在 UI 会话中获得的完全相同的 API 访问权限。
更高权限的操作
这些 API 还将由其他用户和客户端使用，他们可能需要调用更高权限的操作。接下来考虑几个调用相同 API 的员工应用，这些应用也可能暴露在 Internet 上。这些可能允许更高的权限，并需要多重身份验证：
在这里，我还使用了分层作用域，例如 ，这是设计对 API 端点的访问的一种可能技术。不过，范围仍然是高级别的，并且只管理入门级安全性。sales:payments
其他选项
流动令牌有更高级的选项。例如，OAuth 令牌交换可用于在调用上游 API 之前为同一用户获取不同的令牌。最常见的是，这用于为同一用户获取另一个令牌，但范围缩小。
对于上游 API，可以获取具有完全不同范围的令牌，但在某些情况下，这样做可能会削弱安全性。执行此操作的解决方案通常使用客户端凭据流来获取范围为 的令牌，例如 ，然后在无法验证的标头或 URL 路径段中传递用户 ID。因此，令牌可能有权访问太多用户的数据，并且具有此类令牌的恶意方可能会更改用户 ID。billing
单独的基础架构解决方案（例如要求对计费 API 使用双向 TLS）也存在一些问题。它们可能会阻止真正的客户端访问该 API。这可能与企业主的需求背道而驰。在上面的示例中，它会阻止财务应用调用计费 API。
总结
如果需要，基础架构解决方案可能是最好的短期战术解决方案。不过，作为未来的方向，目标是使用 OAuth 提供的零信任组件，以最佳方式使用范围和声明。
评论