当前位置：首页 > 文章列表 > 文章 > 前端 > AWSCognito自定义邮件验证方案

AWSCognito自定义邮件验证方案

2025-08-19 14:00:29 0浏览收藏

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

AWS Cognito与自定义邮件服务集成：无需用户访问令牌的邮箱验证策略

本文探讨了在AWS Cognito中集成自定义邮件发送服务时，如何处理用户邮箱验证码的问题，尤其是在无法获取用户访问令牌的情况下。由于Cognito未直接提供无需用户令牌的验证码验证API，实践中推荐的解决方案是在后端生成、存储并验证自定义验证码。成功验证后，通过AdminUpdateUserAttributes更新Cognito用户属性，将邮箱标记为已验证。这种方法为需要高度定制化邮件流程的应用程序提供了灵活且安全的邮箱验证机制。

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

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

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

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

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

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

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

实施步骤

在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;
```
};
前端接收并提交验证信息： 用户收到邮件后，通过点击链接或手动输入验证码，前端将验证码和用户标识（如邮箱或用户名）发送到您的后端API接口。

后端验证并更新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学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！