AWS Cognito用户池客户端凭证模式部署后失效，仅控制台手动保存后可用

问题根因 #

1. 资源创建顺序缺少显式依赖声明
   CloudFormation默认会并行创建无依赖关系的资源，你的模板里CognitoUserPoolClient没有声明对UserPoolDomain和UserPoolResourceServer的依赖，大概率出现以下时序问题：

• CognitoUserPoolClient先创建完成，此时你配置的AllowedOAuthFlows、AllowedOAuthScopes关联的用户池域名、自定义资源服务器作用域还未创建完成，Cognito后台不会主动重试同步客户端的OAuth配置，导致客户端的OAuth2客户端凭证流程实际处于未生效状态，请求令牌就会返回invalid_grant错误。
• 你在控制台点击保存按钮时，Cognito后台会重新触发全量配置校验、同步逻辑，此时用户池域名、资源服务器都已经创建完成，配置校验通过后客户端的OAuth流程就正常启用了。

2. 作用域配置不匹配（次要问题，也会加剧异常）
   你在CognitoUserPoolClient的AllowedOAuthScopes里配置了myapp/odata4，但在UserPoolResourceServer定义的自定义作用域只有myapp/results和myapp/trigger，不存在odata4这个作用域，部署时Cognito不会直接报错，但会导致作用域配置失效，控制台保存时会自动过滤不存在的作用域，也会让配置临时恢复正常。

修复方案 #

1. 给CognitoUserPoolClient添加显式依赖，确保它在用户池域名、资源服务器都创建完成后再创建：

CognitoUserPoolClient:
  Type: "AWS::Cognito::UserPoolClient"
  DependsOn:
    - UserPoolDomain
    - UserPoolResourceServer
  Properties:
    # 其余原有配置保持不变

2. 修正AllowedOAuthScopes配置，和你定义的资源服务器作用域保持一致：

AllowedOAuthScopes: [ "myapp/results","myapp/trigger" ]

修改后重新部署即可解决每次部署后需要手动保存的问题，实现自动化部署。

控制台保存触发的操作 #

你在Cognito应用客户端页面点击保存时，不管你有没有修改配置，后台都会执行以下操作：

• 拉取当前用户池下所有关联资源（域名、身份提供商、资源服务器、作用域等）的最新状态
• 重新校验客户端的所有OAuth配置、认证流程配置的合法性
• 校验通过后重新写入客户端的全量配置到Cognito的生效配置库，同步到所有Cognito边缘节点
• 触发一次客户端配置的缓存刷新操作

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