Cognito Access Token缺失cognito:groups声明，已开openid仍未解决

• 核对应用客户端的权限与Scope配置

  1. 确认应用客户端的Allowed OAuth Scopes中，除了已开启的openid、aws.cognito.signin.user.admin，还需勾选profile（自定义属性默认归属该Scope）；再次确认aws.cognito.signin.user.admin确实处于启用状态
  2. 检查应用客户端的Read attributes列表，确保cognito:groups及所有需要的自定义属性都被设置为可读权限

• 验证用户与分组的关联有效性

  1. 在Cognito控制台直接查看目标用户的分组归属，确认未被误移除
  2. 用AWS CLI命令手动校验：aws cognito-idp admin-list-groups-for-user --user-pool-id <你的用户池ID> --username <用户名>，排除控制台显示异常的情况

• 检查用户池的属性映射与触发器

  1. 进入用户池App client settings的Hosted UI板块，确认Attribute mapping中cognito:groups和自定义属性已正确映射到对应OAuth声明
  2. 排查是否存在Pre Token Generation Lambda触发器，若有则检查代码是否过滤或修改了access token中的目标声明——新池可能误配置了触发器或逻辑存在问题

• 排查大小写不敏感配置的隐性影响

  1. 新池启用了大小写不敏感，尝试用AWS CLI重新将用户添加到目标分组，再获取token测试，避免用户名大小写差异导致的分组关联隐性失效
  2. 核对新旧池Username configuration中的大小写设置，确认用户存储的username格式无差异，排除配置变更引发的关联问题

• 验证Token获取流程的正确性

  1. 不依赖前端currentAuthenticatedUser，改用Postman直接调用Cognito的/oauth2/token端点，携带完整Scope（openid profile aws.cognito.signin.user.admin）获取access token，解析payload确认是否包含目标声明
  2. 检查前端Amplify的Auth.configure配置，确保scope参数已正确设置所需的全部Scope，避免请求时遗漏

• 核对OAuth流与授权类型配置

  1. 确认新池应用客户端的Allowed OAuth Flows、OAuth 2.0 grant types与旧池完全一致，比如旧池用Authorization Code Flow，新池若改用Implicit Flow可能影响token包含的声明内容

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