amazon-cognito - 打开 ID Connect 并使用 Cognito 承担角色

Question

我想创建一个需要 IAM 角色才能访问最终用户的 S3 存储桶中的数据的 API。我目前使用以下流程:

1. 用户登录网站并获取 ID token 和访问 token (通过 OIDC)。
2. 用户调用我的 API 并出示其 ID token 。
3. 我的 API 使用提供的 ID token 从 Cognito 身份池获取临时凭据。
4. 可以使用临时凭据调用 S3。

尽管这可行，但此流程存在缺陷。网站在 Open ID Connect 登录期间获得了 ID token ，但 ID token 不应用于传递给 API(这就是访问 token 的用途)。我宁愿传递访问 token ，但我无法使用访问 token 获取 AWS 凭证。

这里合适的解决方案是什么？我检查了是否可以从访问 token 获取 ID token 。我有几个选择:

1. 只需将 ID token 传递给 API，因为我们希望传递我们的身份(IAM 角色)，以便 API 可以模拟。这使得传递 ID token 而不是访问 token 变得合理。
2. API 应根据访问 token 获取 ID token 。虽然我可以从 OIDC userinfo 端点获取所有身份声明，但这不是 ID token ，因此我无法使用它通过 Cognito 的身份池获取 AWS 凭证。
3. 完全放弃 Cognito 身份池并授予 API 角色 STS 策略，以便它可以承担与用户关联的角色。我宁愿不在我的服务中担任高权限角色。

这三种解决方案都不理想。但最好的情况是什么？还是我忘记了什么？

Answer 1

这里实际上使用了两种类型的资源:

一般资源和提供商资源

• Cognito 充当通用授权服务器，获取在您的应用中使用的 token 并访问 API 中的数据

• Cognito 还可以充当用户进行身份验证的身份提供者，但这不是唯一的选择

如果您想象 Cognito 流程被更新为通过 Google 登录用户，之后有两种类型的 token ，并且可以使用 Google token 访问用户的 Google 文档，那么第二点就更清楚了。

嵌入 token 模式

参见this Curity article了解分离此类关注点的技术。尽管您没有使用嵌入式 token ，但值得理解的是，应用程序有时需要考虑使用不同 token 访问不同资源。

您的场景

重要的考虑因素是将您自己的资源的通用 API 授权基于访问 token - 正如您所建议的那样。这将使您的主要 API 逻辑基于标准并可移植。旨在将其与供应商特定行为分开。

对于需要访问 S3 或其他 AWS 资源的 API 操作，您可能必须按照提供商的要求进行操作。 ID token 向 UI 客户端提供身份验证事件的证明，但 AWS 有时将它们用作访问 token 。就我个人而言，我不会为了自己的资源而采用这种方法。相反，除了访问 token 之外，我还会将 ID token 发送到附加 header (例如 x-idp-token)中的特定 API 操作。