我正在AWS中部署基于云原生微服务的应用程序。此应用程序应使用基于OIDC的IdP认证和授权流程如下：一旦用户使用授权代码流登录，IdP生成一个ID标记和访问标记。访问标记被发送到后端服务以进行后端调用。如果需要，后端服务可以通过/userinfo终结点获取用户信息。此外，访问令牌具有所需的组声明和范围，以确定是否存在正确的访问权限。现在，如果后端服务需要代表登录用户调用下游后端内部微服务，那么我是否应该创建一个
1.具有客户端凭据的新令牌授予服务调用所需的缩减范围？或
1.我应该只发送用户的初始访问令牌吗？
在第一种情况下，用户上下文在新的访问令牌中丢失，如果下游服务需要用户上下文，那么下游服务将如何获取用户信息？在第二种情况下，下游服务不是使用该服务所需的确切特定范围调用的，因此不是安全性最佳做法。
然而，还有一个授权调用交换授权（https://www.rfc-editor.org/rfc/rfc8693.html），它支持从初始令牌创建一个新的访问令牌，而无需重新登录用户（https://www.rfc-editor.org/rfc/rfc8693.html中的委托模式）。AWS Cognito是否支持它？如果不支持，那么如果我使用AWS Cognito，如何实现相同的功能？
1条答案
按热度按时间vyswwuz21#
这在某种程度上取决于微服务之间的信任级别。默认情况下，如果它们是同一单元的一部分，则目标是这种类型的设置：
orders和shipping然后，如果Orders调用Shipping，则可以通过转发访问令牌来安全地传递用户身份。
每个API还应检查
audience声明是否具有预期值，表示一组相关的API，如api.example.com。我相信目前AWS Cognito不会发布访问令牌的受众声明。如果运输是你公司的一个不太受信任的子部门，代币交换会更合适。例如，如果你担心运输服务滥用订单特权。
避免过度依赖作用域，或使用过多的作用域。使用声明作为主要授权。在Cognito中，您可以在验证JWT之后、API创建其声明主体之前查找这些值
Cognito仅对更高级的令牌行为提供非常有限的支持，如发布自定义声明、引用令牌或令牌共享技术。如果您需要这些功能，首选选项是选择支持这些标准的授权服务器。