AWS API Gateway令牌授权最佳实践：Access Token与Id Token选择答疑

核心选择逻辑 #

• 标准规范视角：按照OAuth2/OIDC的设计，Access Token就是专门为API授权而生的，通过scopes（范围）和claims（声明）实现权限控制，能明确区分身份凭证（Id Token）与权限凭证的职责，这是最合规的方案。
• AWS Cognito场景的折中方案：因为Cognito对Access Token的自定义声明支持有限，但Id Token可以通过预生成Lambda灵活添加/修改声明，官方也给出了用Id Token做细粒度授权的示例。这种方案在当前Cognito的限制下是可行的，但存在两个潜在风险：
  • Id Token的核心定位是身份验证而非授权，用它做授权会模糊OIDC的职责边界，未来如果Cognito调整Id Token的生成规则（比如限制非标准声明），可能直接影响现有授权逻辑。
  • Id Token通常包含用户姓名、邮箱等敏感身份信息，传递给API网关会增加数据暴露的风险，而Access Token可以仅包含必要的权限相关信息。

Access Token的灵活使用方案 #

如果想坚持遵循标准，用Access Token实现灵活授权，可以尝试以下思路：

• 配置Cognito自定义作用域（Custom Scopes）：在用户池客户端中创建自定义scopes，把权限信息嵌入其中，API网关通过验证scopes来控制访问权限。
• 搭配Lambda授权器：在授权器逻辑里，通过Access Token中的用户标识（如sub）调用Cognito用户信息接口，或者从DynamoDB等存储中读取用户的权限声明，再完成授权判断。这种方式既符合Access Token的设计初衷，又能实现灵活的权限控制。

总结建议 #

• 若当前项目对权限自定义需求高，且短期内不打算更换身份提供商，可以暂时用Id Token配合预生成Lambda实现授权，但要做好代码解耦，未来Cognito放开Access Token自定义支持后及时迁移。
• 优先推荐Access Token+Lambda授权器的方案，虽然多了一步权限查询，但更符合标准规范，扩展性更强，能规避未来Id Token规则变动带来的风险。

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