AWSCognito自定义邮件验证方案

欢迎各位小伙伴来到golang学习网，相聚于此都是缘哈哈哈！今天我给大家带来《AWS Cognito集成自定义邮件服务：无令牌邮箱验证方案》，这篇文章主要讲到等等知识，如果你对文章相关的知识非常感兴趣或者正在自学，都可以关注我，我会持续更新相关文章！当然，有什么建议也欢迎在评论留言提出！一起学习！

Cognito的默认验证机制与自定义需求

AWS Cognito提供了一套完整的用户管理和认证解决方案，其中包括用户邮箱验证功能。在标准流程中，Cognito可以自行发送验证邮件（通过SES），用户点击邮件中的链接或在前端输入收到的验证码后，通常会通过Cognito SDK或API在用户已认证（拥有Access Token）的上下文中完成验证。例如，CognitoIdentityProvider.GetUserAttributeVerificationCode或VerifyUserAttribute等API都需要有效的用户访问令牌（Access Token）来操作。

然而，在某些场景下，开发者可能需要更高度的定制化：

1. 使用自定义邮件发送服务： 不使用Cognito内置的SES发送功能，而是通过Lambda触发器（Custom Message Lambda Trigger）调用第三方邮件服务发送验证邮件。
2. 自定义前端验证页面： 希望用户在前端的特定页面输入验证码或点击验证链接，并将验证逻辑交由后端处理，而不是直接通过Cognito SDK在前端完成验证。
3. 无用户访问令牌的后端验证： 在后端接收到验证码和用户信息后，需要在没有用户Access Token的情况下，以“管理员”权限完成邮箱验证。

在上述第三种情况下，Cognito并未直接提供一个API，允许后端仅凭用户名和验证码，在没有用户Access Token的情况下，以管理员身份验证用户邮箱。例如，AdminUpdateUserAttributes可以修改用户属性，但它并非用于验证码的校验。而像GetUserAttributeVerificationCode这样的API，其设计初衷是让已认证的用户请求或验证自己的属性，因此需要Access Token。

解决方案：后端自主管理验证码

鉴于Cognito在无用户访问令牌场景下，缺乏直接的验证码校验API，最实际且灵活的解决方案是：由后端系统自主生成、存储、发送和验证邮箱验证码。 一旦验证码在后端成功校验，再通过Cognito的管理员API更新用户邮箱的验证状态。

实施步骤

1. 在Cognito Lambda Hook中生成并发送自定义验证码： 当用户注册或请求邮箱验证时，Cognito会触发Custom Message Lambda Trigger。在这个Lambda函数中，您可以：

   • 生成一个唯一、有时效性的验证码（例如，6位数字或字母数字组合）。
   • 将此验证码与用户ID（或用户名/邮箱）关联起来，并存储在您的后端数据存储中（如数据库、Redis等），并设置过期时间。
   • 通过您的自定义邮件发送服务，将包含此验证码的验证链接或直接的验证码发送给用户。验证链接通常指向您前端的验证页面，并包含验证码和用户标识符（如邮箱）。

     // 示例：Custom Message Lambda Trigger 中的概念代码
     const generateVerificationCode = () => {
     // 生成一个随机的6位数字验证码
     return Math.floor(100000 + Math.random() * 900000).toString();
     };

   exports.handler = async (event) => { if (event.triggerSource === 'CustomMessage_SignUp' || event.triggerSource === 'CustomMessage_ResendCode') { const username = event.userName; const email = event.request.userAttributes.email; const verificationCode = generateVerificationCode();

       // TODO: 将 verificationCode 存储到您的数据库/Redis中，并关联到 username/email，设置过期时间
       console.log(`Generated code for ${email}: ${verificationCode}`);
   
       // 构建验证链接，发送给用户
       const verificationLink = `https://my-frontend.com/verify-email?code=${verificationCode}&email=${encodeURIComponent(email)}`;
   
       // TODO: 调用您的自定义邮件服务发送邮件，邮件内容包含 verificationLink 或 verificationCode
       event.response.emailMessage = `您的验证码是：${verificationCode}。或者点击链接验证：${verificationLink}`;
       event.response.emailSubject = '请验证您的邮箱';
   }
   return event;

   };

2. 前端接收并提交验证信息： 用户收到邮件后，通过点击链接或手动输入验证码，前端将验证码和用户标识（如邮箱或用户名）发送到您的后端API接口。

3. 后端验证并更新Cognito用户状态： 您的后端API接收到验证请求后：

   • 从您的数据存储中检索与用户关联的存储验证码。
   • 比较前端提交的验证码与存储的验证码是否匹配，并检查验证码是否已过期或已被使用。
   • 如果验证成功，则调用AWS SDK的CognitoIdentityProvider.adminUpdateUserAttributes API，将用户的email_verified属性设置为true。

   const AWS = require('aws-sdk');
   const cognitoidentityserviceprovider = new AWS.CognitoIdentityServiceProvider();
   
   /**
    * 在后端验证自定义验证码，并在Cognito中标记邮箱为已验证。
    * @param {string} userPoolId Cognito用户池ID
    * @param {string} username Cognito用户名 (通常是邮箱或用户ID)
    * @param {string} submittedCode 用户提交的验证码
    */
   async function verifyEmailAndMarkAsVerified(userPoolId, username, submittedCode) {
       // 步骤1: 从您的数据库/Redis中获取存储的验证码
       // 假设您有一个函数来获取存储的验证码和其过期时间
       // const storedVerificationData = await getStoredCodeFromDB(username);
       // if (!storedVerificationData || storedVerificationData.code !== submittedCode || isExpired(storedVerificationData.expiryTime)) {
       //     throw new Error('Invalid or expired verification code.');
       // }
   
       // 实际应用中，这里会进行数据库查询和验证码匹配逻辑
       console.log(`Verifying code for ${username}...`);
       // 模拟验证成功
       const verificationSuccessful = true; // 替换为实际的验证逻辑
   
       if (verificationSuccessful) {
           const params = {
               UserAttributes: [{
                   Name: 'email_verified',
                   Value: 'true'
               }],
               UserPoolId: userPoolId,
               Username: username
           };
   
           try {
               await cognitoidentityserviceprovider.adminUpdateUserAttributes(params).promise();
               console.log(`User ${username} email marked as verified in Cognito.`);
               // TODO: 从数据库中删除或标记已使用的验证码
           } catch (error) {
               console.error(`Error updating user attributes for ${username}:`, error);
               throw error;
           }
       } else {
           throw new Error('Verification code mismatch or other validation error.');
       }
   }
   
   // 示例后端API路由调用 (Node.js Express 框架概念)
   // app.post('/api/verify-email', async (req, res) => {
   //     const { email, code } = req.body;
   //     const userPoolId = 'YOUR_COGNITO_USER_POOL_ID'; // 从环境变量或配置中获取
   //     try {
   //         // 需要根据email找到Cognito的username，如果username不是email本身
   //         // 假设username就是email
   //         await verifyEmailAndMarkAsVerified(userPoolId, email, code);
   //         res.status(200).json({ message: 'Email verified successfully.' });
   //     } catch (error) {
   //         res.status(400).json({ error: error.message });
   //     }
   // });

注意事项与最佳实践

• 验证码安全性：
  • 随机性与长度： 确保生成的验证码足够随机且长度适中，难以被猜测或暴力破解。
  • 时效性： 为验证码设置合理的过期时间（例如5-15分钟），过期后即失效。
  • 单次使用： 验证码一旦成功使用，应立即失效，防止重复使用。
  • 防暴力破解： 在后端实现对验证尝试次数的限制，例如在一定时间内，针对同一用户或IP地址的验证失败次数达到阈值后，暂时锁定或增加验证难度。
• 数据存储：
  • 选择可靠且访问速度快的数据存储方案来保存验证码，例如Redis（用于缓存和过期管理）或数据库（如DynamoDB、PostgreSQL）。
  • 确保存储的验证码与用户正确关联，并且能够高效检索。
• 错误处理：
  • 清晰地向前端返回验证失败的原因，例如“验证码无效”、“验证码已过期”或“系统错误”。
• 用户体验：
  • 提供重新发送验证码的选项，但要限制重新发送的频率，以防止滥用。

总结

尽管AWS Cognito在集成自定义邮件服务时，并未提供直接的“管理员”API来验证其自身生成的验证码而无需用户访问令牌，但通过在后端自主管理验证码流程，我们依然能够实现高度定制化的邮箱验证功能。这种方法涉及在Lambda Hook中生成并存储验证码，通过自定义邮件服务发送，并在后端接收用户提交的验证码后进行校验，最终通过AdminUpdateUserAttributes更新Cognito中用户的邮箱验证状态。这不仅解决了特定场景下的技术难题，也为应用程序带来了更大的灵活性和控制力。

今天关于《AWSCognito自定义邮件验证方案》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！