AWS Cognito：用户管理与身份验证
AWS Cognito 提供了一种可靠且可扩展的用于 Web 和移动应用的用户管理与身份验证的解决方案，无需自行运行身份后端。该服务集成外部身份提供者并为 API 提供符合标准的令牌。此外，它还实现将身份令牌兑换为临时的 AWS 凭证，以便直接访问 AWS 服务，如 S3 和 DynamoDB。
Quelle: 自定义展示
AWS Cognito 基础知识
AWS Cognito 由两大核心组件组成：用户池和身份池。
用户池 是一个用户目录和一个 OpenID-Connect-kompatibler Identity Provider. 它们对用户进行身份验证，颁发 ID、Access 和 Refresh 令牌，并通过 OIDC 或 SAML 集成社交或企业身份提供者。
身份池 （也称为联合身份）基于这些身份提供 kurzlebige AWS-Credentials. 这对尚未登录的访客也是可能的。
托管的登录页，早先称为“Hosted UI”，现在称为“Managed Login”，提供
standardkonforme OAuth-Endpunkte 可用，其中包括
/oauth2/authorize, /oauth2/token, /logout 以及 OIDC Discovery- OIDC Discovery- 和 JWKS-Ressourcen.
Für Single Page Applications (SPAs) ist der
Authorization-Code-Flow mit PKCE von zentraler Bedeutung, da er verhindert, dass abgefangene Codes missbraucht werden können.
输出的令牌是 JSON Web Tokens (JWTs). 访问令牌承载 API 授权所需的作用域和组，而 ID 令牌包含个人资料信息。这些令牌的签名可以通过各自池的 JWKS-URL 进行验证。
当前状态与功能
令牌寿命可以按应用客户端进行精确设置。Access-令牌和ID-令牌可以在 5 Minuten und 1 Tag 之间进行配置。刷新令牌的默认有效期为 30 天，但在之间可以进行调整。 60 Minuten und 10 Jahren 进行调整。
托管登录页支持 PKCE standardmäßig. 该 Logout-Endpunkt 结束浏览器会话并重定向到配置的登出 URL。
Quelle: aws.amazon.com
Amazon Cognito 的核心功能概览。
为了实现个性化品牌形象和使用自有域名，可以设置一个 Custom Domain mit einem ACM-Zertifikat （需要 us-east-1 区域的证书）。之后，登录将通过自有子域名进行。
API 可以直接在 API Gateway 上使用一个 JWT-Authorizer 受保护，Cognito 作为 OIDC-发行者被接受，或通过自定义的（Lambda）授权器。
该 adaptive/risikobasierte Anmeldung („Threat Protection“) 可以对可疑的登录尝试进行评分、强制多因素认证（MFA）或阻止访问。
对于多租户应用，AWS 记录了多种模式，从一个 Single-Pool-Ansatz bis hin zu einem Pool pro Tenant, 包括通过组/角色与作用域实现的隔离。
在 Next.js 应用中的集成由该 Cognito-Provider von NextAuth 简化。会话通过 JWT/Cookies 管理，边缘中间件保护路由。
背景与动机
现代应用需要一个中心身份层，支持行业标准，如 OIDC/OAuth2/SAML ，通过多因素认证（MFA）和自适应身份验证来应对风险，并同时实现对自有身份提供者的集成。对于 SPAs， PKCE unverzichtbar, 因为浏览器无法安全地存储客户端密钥；Cognito 完全实现 PKCE。
在 API 端，直接的 JWT-Abgleich am API Gateway 有吸引力。它提供低延迟、清晰的身份验证（AuthN）与授权（AuthZ）分离，并避免对用户存储的额外往返。
合规性与数据驻留是另一个重要方面。User Pools 在区域内存储档案数据。可选特性如 Pinpoint-Analytics 可以将数据发送到其他区域，这对 EU/CH 团队相关，并且 besondere Beachtung erfordert.
Quelle: YouTube
本视频展示了 SAML-Föderation mit Cognito, 这有助于直观地理解基于 IdP 的场景和单点登出。
实际应用与建议
如果你正在开发 SPA 或 Next.js 应用，应选择 Authorization Code Flow mit PKCE 选择。令牌应在服务器端通过 httpOnly Cookies 存储，或使用框架的会话机制。JWT 的校验应始终针对该 JWKS-Endpunkt des Pools 进行。
Quelle: economize.cloud
使用 AWS Cognito 的典型认证流程。
API 应检查作用域并使用一个 JWT-Authorizer 来实现认证和授权的解耦并降低延迟。
对于多租户应用，建议从一个 Single-Pool-Ansatz 开始，辅以租户属性或作用域。若有严格的隔离要求，可以考虑为每个租户设一个池。
在运营领域，建议 CloudTrail und CloudWatch-Metriken 启用以监控配额和登录模式，并可选地使用 Threat Protection 该功能。
就合规而言，必须检查区域数据流（例如通过分析），并为 EU/CH 团队记录，特别是在考虑到 regionalen Datenüberlegungen.
Quelle: YouTube
本演练有助于 Authorization-Code-Flow mit PKCE 端到端地理解。
未解答的问题与挑战
令牌 TTL 与轮换的设计需要仔细权衡，在用户体验和安全性之间达到平衡，而不强迫应用频繁刷新。AWS 建议，令牌仅用于大约 75 Prozent ihrer Lebenszeit 使用，并在之后再刷新。
问题在于，通过组/作用域进行的租户隔离在何种程度上足以在池分割在组织与成本方面成为必要之前。AWS 描绘了两条路径，但可行的阈值是 anwendungsabhängig.
Quelle: aws.amazon.com
将 Cognito 与外部身份提供者和 AWS 服务集成。
在启用像 Pinpoint 这样的可选功能时，哪些数据可以根据各自的合规规则离开区域？这里是 regionalen Hinweise 需要进行检查并记录选择加入。
在所有连接的 IdP 中实现单点登出的一致性是另一个挑战。对 SAML 来说有 SLO-Unterstützung, 但实现细节因 IdP 而异。
结论： AWS Cognito 提供一个稳健、基于标准的身份验证核心，具备明确的扩展点：带 PKCE 的托管登录、干净的 JWT 验证，以及对社交或企业 IdP 的可选联合。在实践中，关键是为应用选择合适的流程，明确令牌的有效期并通过 API 层严格基于作用域进行授权。在多租户架构的规划中，应尽早就隔离边界和运行指标做出决定。构件已就位，设计决策取决于用户。