基于Open ID Connect与Cognito Assume Role的S3访问方案优化咨询

这个方案可以完全满足你只传递access token的需求，同时避免引入高权限角色，适配现有技术栈：

• 前置配置：在Cognito Identity Pool中开启开发者自定义身份提供商，将你的OIDC issuer配置为可信的开发者身份提供商
• 流程调整：
  1. 用户登录后仅传递access token调用API，符合OIDC规范要求
  2. API侧首先校验access token的合法性（校验签名、issuer、audience、过期时间，这一步和普通API授权逻辑一致）
  3. 校验通过后，API调用Cognito的GetOpenIdTokenForDeveloperIdentity接口，传入从access token中提取的用户唯一标识（比如sub字段）和身份提供商信息，获取Cognito签发的合法ID token
  4. 使用该Cognito ID token从Cognito Identity Pool换取STS临时凭证，后续正常调用S3接口即可
• 权限控制：仅需要为API执行角色授予cognito-identity:GetOpenIdTokenForDeveloperIdentity的窄权限，以及对应IAM角色的扮演权限，不存在高权限风险，符合安全要求

如果你不想修改Cognito侧配置，也可以选择以下两种落地性较高的方案：

方案1：API Gateway Lambda授权器集成 #

如果你的API部署在AWS API Gateway之后，可直接配置Lambda自定义授权器：

• 授权器逻辑负责校验前端传入的access token，校验通过后调用Cognito接口获取临时STS凭证
• 将临时凭证加密后注入请求上下文传递给后端API，后端API不需要处理任何token相关逻辑，进一步降低安全风险

方案2：前端凭证本地化处理 #

如果你的业务不需要API做S3的中间数据处理，可直接让前端在本地完成凭证兑换：

• 前端登录拿到ID token后，本地调用Cognito Identity Pool接口换取STS临时凭证
• 前端调用API时仅传access token做业务授权，访问S3时直接使用本地存储的临时凭证，完全避免ID token传递到后端服务
  该方案仅适用于不需要API统一管控S3访问的场景，需做好前端临时凭证的存储安全防护

你梳理的三个方案并非完全不可用，可根据业务安全等级选择：

• 方案1（直接传ID token）：如果你的API和前端同属可信域，且ID token的audience配置包含API的标识，该方案的落地成本最低，不符合规范但无直接安全风险
• 方案2（API拿access token换ID token）：如果你的OIDC提供商支持token introspection接口返回完整的签名ID token，可以直接用该结果兑换Cognito凭证，不需要改动其他逻辑
• 方案3（直接用STS扮演用户角色）：如果用户数量较少且角色规则清晰，可通过STS标签限制角色可访问的S3资源，将API角色的权限收敛到仅能扮演指定前缀的用户角色，同样可以规避高权限风险

内容的提问来源于stack exchange，提问作者Ramon de Klein