如何通过CloudFormation更新Cognito用户池客户端RefreshTokenValidity并保留回调URL

问题核心 #

CloudFormation是声明式基础设施管理工具，它会严格按照模板定义的配置同步资源状态。如果模板里只指定了部分CallbackURLs，更新时CloudFormation会将用户池客户端的回调URL列表完全替换为模板内容，手动添加的Salesforce回调URL自然会被清空。

解决方案 #

方案1：将所有回调URL写入模板（推荐）

把包括Salesforce在内的所有需要的回调URL都明确写进模板的CallbackURLs列表，这样CloudFormation每次更新时都会确保这些URL全部保留，不会丢失。

修改后的模板片段：

DemoCognitoOpenIdClient:
  Type: AWS::Cognito::UserPoolClient
  Properties:
    UserPoolId: !Ref CognitoUserPool
    ClientName: DemoCognitoOpenIdClient
    GenerateSecret: true
    ExplicitAuthFlows:
      - ALLOW_REFRESH_TOKEN_AUTH
      - ALLOW_USER_SRP_AUTH
      - ALLOW_CUSTOM_AUTH
      - ALLOW_USER_PASSWORD_AUTH
      - ALLOW_ADMIN_USER_PASSWORD_AUTH
    AllowedOAuthFlowsUserPoolClient: true
    AllowedOAuthScopes:
      - openid
      - phone
      - email
    TokenValidityUnits:
      AccessToken: hours
      IdToken: hours
      RefreshToken: days
    AuthSessionValidity: 3
    RefreshTokenValidity: 190  # 可直接修改为目标时长
    AccessTokenValidity: 1
    IdTokenValidity: 1
    EnableTokenRevocation: true
    PreventUserExistenceErrors: ENABLED
    SupportedIdentityProviders:
      - "COGNITO"
    CallbackURLs:
      - https://*.zyx.com
      - https://*.xyz.com
      - https://your-salesforce-callback-url.com  # 新增Salesforce回调URL
    AllowedOAuthFlows:
      - "code"

这种方式的优势是所有配置都在代码中管理，状态可追溯、可重复部署，避免手动操作带来的不一致。

方案2：用Lambda自定义资源同步URL（适用于无法提前知晓所有URL的场景）

如果有其他团队手动添加回调URL，无法全部写入模板，可以通过CloudFormation自定义资源+Lambda函数实现增量更新：

1. 编写Lambda函数：
   • 调用DescribeUserPoolClient接口读取现有回调URL列表
   • 合并需要保留的额外URL（可从SSM参数存储、配置文件读取）
   • 调用UpdateUserPoolClient接口更新客户端，确保所有必要URL都存在
2. 在模板中添加自定义资源：
   • 让自定义资源依赖于DemoCognitoOpenIdClient，确保用户池客户端更新完成后再触发Lambda执行，每次模板更新时自动同步所有回调URL。

方案3：用AWS Config规则监控恢复（事后补救）

创建AWS Config规则监控Cognito用户池客户端的CallbackURLs属性：

• 当检测到指定的回调URL（如Salesforce的）被删除时，自动触发API调用恢复URL，或发送告警通知人工处理。
• 这种方式属于事后补救，适合无法避免手动修改的场景，但不如前两种方案主动。

最佳实践 #

尽量避免手动修改CloudFormation管理的资源配置，所有变更通过模板实现，保证基础设施状态的一致性和可追溯性。若必须手动添加配置，需通过自定义资源或监控规则同步状态。

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