我遇到的问题是关于多个后端服务之间的令牌共享和用户模拟。
Web服务A（我拥有）=〉用户可以使用用户名+密码登录=〉我选择使用AWS Cognito来验证用户身份，Cognito将返回一个JWT access_token，其中用户名在claims中。我将Authentication和Authorization分开，Cognito只负责Authentication部分，我得到了另一个服务来处理Authorization。
授权服务：传入用户名（从access_token中提取）和资源。服务将只返回grant或deny
后端服务B（我拥有）=〉Web服务A需要向服务B发送API请求，但我希望对服务B的信任为零，因此我不会在服务B中使用相同的用户访问令牌。
后端服务C（我拥有）=〉后端服务B将向服务C发送API请求
我必须使用AWS Cognito进行所有令牌生成等...... Cognito不支持令牌交换授权类型。
我遇到的问题是关于多个后端服务之间的令牌共享。
Web服务A（我拥有）=〉用户可以使用用户名+密码登录=〉我选择使用AWS Cognito来验证用户身份，Cognito将返回一个JWT access_token，其中用户名在claims中。我将Authentication和Authorization分开，Cognito只负责Authentication部分，我得到了另一个服务来处理Authorization。
授权服务：传入用户名（从access_token中提取）和资源。服务将只返回grant或deny
后端服务B（我拥有）=〉Web服务A需要向服务B发送API请求，但我希望对服务B的信任为零，因此我不会在服务B中使用相同的用户访问令牌。
后端服务C（我拥有）=〉后端服务B将向服务C发送API请求
我必须使用AWS Cognito进行所有令牌生成等...... Cognito不支持令牌交换授权类型。
我的想法是：使用client_credential流+用户的access_token。
当服务A获取到用户的access_token后，会使用Authorization service验证访问服务B的权限，然后使用client_credentials流向Cognito发送token创建请求，其中包含服务B的client_id和client_secret，client_credentials流返回的机器access_token会丢失用户上下文。所以我也把用户的access_token放在请求头中，所以当请求到达服务B时，B会验证机器access_token和用户的access_token，然后从用户的access_token中提取用户名，并与Authorization service验证权限
服务B与服务C之间的通信将使用相同的逻辑
服务B将使用服务C的client_id + client_secret获取机器access_token，并将用户access_token传递给服务C。服务C将验证机器access_token和用户access_token，然后使用Authorization service验证用户对服务C的权限。
不确定这个想法是否可行？
1条答案
按热度按时间vi4fp9gy1#
这里有一个更好、更简单的选择，因为你拥有所有的服务，那就是使用作用域，结合令牌转发。类似于这样，尽管根据你的业务数据区域来命名作用域：
服务A可以将用户的JWT访问令牌转发给服务B，依此类推。每个服务都验证JWT的数字签名，并检查自己所需的范围。
这为您提供了一个零信任体系结构，其中用户身份以可验证和可审计的方式流动。客户端凭据流将无法实现这一点。当涉及多个用户时，例如在解决技术问题时，管理员以客户身份登录时，将使用模拟解决方案。
更新/示例
A、B和C通常代表高级业务领域。例如，分配
orders、delivery和billing的客户端范围可能是一个例子，其中客户端仅直接与Orders API交互。只要您保持范围高级别，这在客户端中就很容易推理。令牌交换并不会提升作用域，相反，它通常用于在将访问令牌转发给不太受信任的API之前缩小作用域。
当然，更改作用域的方法是通过客户端凭证流获取新的访问令牌。通常，这应该用于对非用户资源进行操作，其中不需要用户身份，因此与用户同意没有潜在冲突。