调用AdminLinkProviderForUser关联Cognito账户后主账户email_verified变为false怎么办

问题结论 #

这个行为是AWS Cognito的预期行为。

背后的设计逻辑 #

Cognito处理外部身份提供商（Google/Apple等）注册的流程中，属性合并操作执行时机在预注册Lambda运行结束之后：当你调用AdminLinkProviderForUser完成账户关联后，Cognito会默认用外部IDP返回的用户属性，覆盖关联的目标本地Cognito账户的同名字段。
绝大多数第三方IDP返回的身份凭证中不会显式携带email_verified声明，Cognito在属性合并时如果没有拿到这个字段的有效值，就会自动把目标账户的email_verified重置为false。
这也是你之前两个修复方案无效的原因：

• 预注册触发器内手动更新用户属性后，后续的属性合并逻辑会直接覆盖修改后的值
• autoConfirmUser、autoVerifyEmail仅对新注册的独立用户生效，对已存在的关联目标账户不生效

可行的修复方案 #

你可以选择以下任意一种方案解决问题：

方案1：预注册阶段显式指定属性值 #

在预注册Lambda调用完关联接口后，直接修改事件对象的用户属性，指定email_verified为true，后续Cognito执行属性合并时就会沿用这个值，不会重置。修改后的代码片段示例：

await client.send(linkProviderCommand);

// 新增：显式指定邮箱已验证，避免后续合并时被重置
event.request.userAttributes.email_verified = "true";
event.response.autoConfirmUser = true;
event.response.autoVerifyEmail = true;

注意如果你的场景下第三方IDP返回的邮箱可能未验证，可以先判断IDP传入的event.request.userAttributes.email_verified值，确认是true后再赋值，避免安全风险。

方案2：使用后确认（Post Confirmation）触发器修正属性 #

如果你的用户池配置不允许在预注册阶段修改属性，可以新增后确认触发器，在该触发器中调用AdminUpdateUserAttributes接口，将关联后的目标账户email_verified属性更新为true，这个阶段属性合并已经完成，修改不会再被覆盖。

内容的提问来源于stack exchange，提问作者Pavol Hlavatý