基于Cognito Token的APIGW认证授权设计：如何通过REST实现实体认证

适配方案：使用Cognito用户池的公开TOKEN REST端点完成认证 #

你不需要为每个实体单独创建App Client，仅需创建1个启用了USER_PASSWORD_AUTH认证流的公共App Client（无需配置客户端密钥，避免密钥泄露风险）即可，所有实体共用该App Client完成认证。

具体实现步骤： #

• Cognito侧配置
  1. 打开Cognito用户池控制台，进入「应用程序集成」页签，创建新的App Client
  2. 认证流勾选「允许用户密码身份验证 (USER_PASSWORD_AUTH)」，不要勾选「生成客户端密钥」
  3. 保存后记录该App Client的ID备用
• 无SDK获取Token的REST调用方式
  直接向Cognito用户池的OAuth 2.0 Token端点发送POST请求即可，请求格式如下：

  POST https://<你的Cognito用户池域名>/oauth2/token
  Content-Type: application/x-www-form-urlencoded
  
  grant_type=password&
  client_id=<你创建的App Client ID>&
  username=<实体的用户名>&
  password=<实体的密码>
  

  调用成功后会返回id_token、access_token和refresh_token，其中id_token默认包含实体唯一标识sub字段，可用于身份识别。
• APIGW侧数据隔离实现
  1. 将APIGW的认证方式配置为「Cognito用户池授权器」，关联你使用的Cognito用户池
  2. 后端服务（例如Lambda）读取APIGW转发请求头中解析后的sub字段，将其作为过滤条件查询订单数据，即可实现不同实体调用同一个getOrders接口时，仅返回自身关联的订单数据。

过往评估方案的误区修正： #

• 带scope的OAuth认证你使用了错误的认证流：client_credentials流本身是服务级身份认证方案，天然无法区分用户级实体；你需要使用的是password授权流，属于用户级认证，可天然区分不同实体。
• 不需要调用需要AWS SigV4签名的Cognito原生管理API，使用公开的OAuth 2.0端点不需要计算签名，也不需要依赖AWS SDK，纯REST调用即可完成全流程认证。

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