AWS Cognito是否支持Token Exchange Grant？微服务代用户调用方案咨询

核心场景与问题 #

你在AWS上部署云原生微服务，采用AWS Cognito作为OIDC身份提供商，用户通过授权码流获取ID Token和Access Token，后端服务依赖Access Token的组声明、权限范围做授权，必要时调用/userinfo获取用户信息。当前核心问题是：后端服务需要代表已登录用户调用下游内部微服务时，如何平衡用户上下文保留和最小权限原则，同时想了解AWS Cognito对RFC 8693 Token Exchange Grant的支持情况。

现有方案的利弊 #

方案1：Client Credentials Grant生成服务级Token #

• 优势：生成仅包含服务调用所需最小权限的Token，符合安全最佳实践。
• 劣势：完全丢失用户上下文，下游服务无法获取用户相关信息，无法基于用户身份做细粒度授权。

方案2：直接转发用户初始Access Token #

• 优势：完整保留用户上下文，下游服务可直接使用Token中的声明或调用/userinfo获取用户信息。
• 劣势：违反最小权限原则——初始Token可能包含远超当前下游服务所需的权限，转发过程中扩大了Token的使用范围，增加泄露后被滥用的风险。

AWS Cognito对Token Exchange Grant的支持 #

目前AWS Cognito不原生支持RFC 8693定义的Token Exchange Grant，无法直接通过标准流程生成带用户上下文的受限委托Token。

替代实现方案（模拟委托模式） #

1. 自定义Lambda扩展Token逻辑 #

利用Cognito的Pre Token Generation Lambda触发器，结合后端服务的Token转换逻辑，生成带用户上下文的受限Token：

• 后端服务先验证用户初始Access Token的有效性（通过Cognito JWKS端点验证签名、过期时间等）。
• 调用自定义Lambda，传入初始Token解析出的用户声明（如用户ID、组）、目标下游服务的权限范围。
• Lambda生成符合JWT标准的新Token：仅包含下游服务所需的权限，同时保留必要的用户上下文字段；使用Cognito的密钥或AWS KMS对Token签名，确保下游服务可验证其合法性。
• 下游服务验证新Token的签名和声明，完成授权和用户信息获取。

2. IAM Roles Anywhere结合用户身份 #

通过IAM Roles Anywhere将用户Cognito身份转换为临时IAM凭证，附带用户上下文：

• 后端服务基于用户的Cognito ID Token，向IAM Roles Anywhere请求临时IAM角色凭证，同时在请求中嵌入用户上下文（如用户ID、组标签）。
• 下游服务通过验证IAM凭证的权限，以及凭证附带的用户标签，实现授权和用户信息获取。
• 适合依赖IAM权限模型的下游服务，无需额外维护JWT验证逻辑。

3. 搭建内部Token代理服务 #

构建专门的内部Token代理服务，统一处理Token转换：

• 后端服务将用户初始Access Token、目标服务标识发送给代理服务。
• 代理服务验证初始Token有效性后，调用Cognito /userinfo API获取完整用户信息，生成仅包含下游服务所需权限的新Token，同时注入必要的用户上下文。
• 下游服务只接受代理服务生成的Token，通过预共享密钥或KMS签名验证合法性。
• 适合多服务、复杂权限场景，便于集中管理Token转换规则。

最终建议 #

如果下游服务需要同时满足用户上下文保留和最小权限，优先选择自定义Lambda扩展Token逻辑——它直接集成在Cognito生态中，实现成本低、可控性强；如果你的微服务体系依赖IAM权限模型，可考虑IAM Roles Anywhere方案；复杂多服务场景下，内部Token代理服务能提供更灵活的规则管理。

内容的提问来源于stack exchange，提问作者Arindam Ghosh