AWS Cognito用户被提前确认：验证链接遭后台调用致验证码过期

可能原因及修复方案 #

1. 邮件服务商的链接预抓取触发API #

多数主流邮件服务（如Gmail、企业邮箱）会自动预加载邮件内链接做安全扫描，这会提前调用你的API Gateway验证端点，导致用户被提前确认。

• 修复方式：
  • 将验证API改为仅接受POST请求：邮件预抓取通常只会发起GET请求，可让邮件链接跳转至前端页面，再由页面通过POST请求调用验证接口
  • 加入nonce验证机制：在Custom Message Lambda生成链接时，生成随机nonce并存入用户Cognito自定义属性；confirm_user Lambda需先验证请求中的nonce与用户属性匹配，才执行确认操作，无效nonce直接拒绝
  • 增加用户交互要求：验证页面需用户手动点击“确认”按钮才发起验证请求，避免自动触发

2. Custom Message Lambda代码误发起请求 #

检查你的Custom Message Lambda代码，是否残留了测试用的API调用逻辑，或在生成链接时不小心发起了请求。

• 修复方式：
  • 查看Lambda的CloudWatch日志，确认是否有发起API请求的记录
  • 清理代码中的调试、测试请求代码，确保仅生成链接字符串，不执行任何请求操作

3. API Gateway的监控/自动测试请求 #

检查API Gateway是否配置了CloudWatch Synthetics监控，或有第三方监控工具定期请求验证端点。

• 修复方式：
  • 查看API Gateway访问日志，通过请求IP、User-Agent判断是否为监控类请求
  • 给API Gateway添加访问控制：比如限制User-Agent为浏览器类型，或限定请求来源IP范围

4. Cognito触发器配置错误 #

确认Cognito用户池仅配置了Custom Message触发器，未误加Post Confirmation等会触发confirm_user Lambda的其他触发器。

• 修复方式：
  • 登录AWS控制台，进入用户池“触发器”页面，核对所有已配置触发器，确保仅Custom Message关联了你的Lambda
  • 查看confirm_user Lambda的CloudWatch日志，定位请求触发来源，确认是否为Cognito其他触发器发起

验证步骤 #

• 使用无链接预抓取功能的小众邮箱测试，点击验证链接确认是否正常，以此排查是否为邮件服务商问题
• 在confirm_user Lambda中添加详细日志，记录请求IP、User-Agent、参数等信息，便于定位请求发起方

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