云应用的前门：使用 Amazon Cognito 简化身份验证
Source: Dev.to
介绍
当我们用沙子、纸板或泡沫搭建童年堡垒时，只有在加上前门后结构才显得完整。在软件中，应用程序的“前门”就是它的身份验证系统。最初的一个简单登录表单很快就会扩展为功能齐全的身份管理解决方案。
为什么从头构建认证系统很困难
典型的早期实现包括：
- 将用户存储在数据库中
- 对密码进行哈希处理
- 提供登录端点
随着应用的增长，额外的安全需求会出现：
- 账户验证（电子邮件/电话）
- 密码重置流程
- 多因素认证（MFA）
- 身份联合（Google、Apple、企业 SSO）
- 安全的 API 授权
设计、实现并安全维护所有这些功能需要大量的工作和持续的警惕。
Amazon Cognito 概述
Amazon Cognito 是由 AWS 提供的托管身份验证和身份管理服务。它让开发者能够专注于核心应用功能，同时将身份验证的复杂性交由服务处理。
关键功能
- 用户注册与登录
- 安全的密码策略与哈希
- 多因素认证（SMS、TOTP）
- 基于令牌的认证（ID、访问、刷新令牌）
- 与社交身份提供商集成（Google、Facebook、Apple、Amazon）
- 通过 SAML 或 OpenID Connect 与企业提供商联邦认证
Source: …
核心组件
用户池
User Pool 是一个完全托管的用户目录，处理身份验证。
功能包括
- 用户注册
- 登录和登出
- 密码恢复以及电子邮件/手机验证
- 强制使用 MFA
当用户成功认证后，Cognito 会颁发身份验证令牌：
- ID Token – 包含用户个人信息
- Access Token – 用于授权 API 调用
- Refresh Token – 在不重新认证的情况下获取新令牌
身份池
身份池（联邦身份）为已认证用户授予临时的 AWS 凭证，使其能够安全访问 AWS 资源，如 S3、DynamoDB 或 API Gateway。
典型认证流程
- 用户通过应用 UI 登录。
- 应用向 Cognito 发送认证请求。
- Cognito 验证凭证。
- 验证成功后，Cognito 返回 ID、访问令牌和刷新令牌。
- 应用在后续 API 请求中包含访问令牌（例如，在
Authorization头部）。 - 后端服务在处理请求前使用 Cognito 验证该令牌。
这种模式消除了后端服务直接管理密码或会话状态的需求；它们只需验证令牌。
与 AWS 服务的集成
Cognito 与以下服务无缝集成：
- API Gateway – 使用 Cognito 授权器保护 REST API
- AWS Lambda – 使用令牌控制函数执行
- Amazon ECS/EKS – 保护服务间通信
- Amazon S3 – 通过临时凭证对对象授予细粒度访问权限
由于 Cognito 是托管服务，它会根据用户数量自动扩展。
联合身份验证
Cognito 支持联合身份提供商，允许用户使用已有账户登录：
- Apple
- Amazon
- 通过 SAML 或 OpenID Connect 的企业 IdP
这种方式简化了用户注册流程，并减少了密码疲劳。
示例用例：国际学生申请平台
一个让学生向全球大学申请的平台需要：
- 创建用户账户
- 上传并存储敏感文件
- 跟踪申请状态
通过集成 Cognito：
- 用户通过 Cognito 管理的 UI 或 SDK 注册并登录。
- Cognito 发放令牌，后端在授予对文档存储或申请数据的访问权限之前进行验证。
- 联合登录（例如 Google）可加快已有账户学生的入职速度。
当 Cognito 可能不是最佳选择
虽然 Cognito 能满足许多应用的需求，但在某些情况下可能需要其他解决方案：
- Cognito 配置选项不支持的高度定制的身份验证流程。
- 具有严格数据驻留要求的本地或混合环境。
- 需要超出 Cognito 内置指标的高级分析或报告功能。
在这些情况下，专门的身份平台或自托管解决方案可能提供更大的灵活性。
结论
认证不仅仅是一个简单的登录页面；它构成了保护应用程序及其用户的安全边界。正如房子需要坚固的前门，现代应用程序也需要可靠的身份和访问管理。Amazon Cognito 提供了一个托管的、可扩展的、功能丰富的“前门”，让开发团队能够专注于构建核心功能，同时将认证复杂性交给可信赖的服务。