AWS Amplify JS 中外部身份提供商登录的 Cookie 存储问题解析

问题背景

在使用 AWS Amplify JS 进行身份验证时，开发者经常会遇到外部身份提供商（如 Google）登录时令牌存储方式不一致的问题。具体表现为：当使用电子邮件/密码登录时，令牌能够正确存储在 Cookie 中，但使用 Google 登录时，令牌却会被存储在 localStorage 中。

技术细节分析

预期行为

AWS Amplify 提供了灵活的存储配置选项，开发者可以通过 cognitoUserPoolsTokenProvider.setKeyValueStorage 方法指定令牌的存储方式。通常推荐使用 CookieStorage 来增强安全性并支持服务器端渲染场景。

实际观察到的行为

在 Google 登录流程中，开发者观察到以下现象：

1. 令牌会先被短暂存储在 localStorage 中（约 0.5 秒）
2. 随后被删除并转移到 Cookie 存储
3. 这种延迟导致某些应用逻辑（如立即重定向）可能无法正确检测到令牌

根本原因

这种行为实际上是设计使然，主要涉及 OAuth 2.0 的安全流程：

1. PKCE 机制：OAuth 2.0 授权码流程需要先在本地存储一个 PKCE（Proof Key for Code Exchange）验证码
2. 安全验证：在重定向到身份提供商之前存储，用于后续的令牌交换验证
3. 流程完整性：这是 OAuth 2.0 安全规范的一部分，防止中间人攻击

解决方案与实践建议

正确配置方法

开发者应确保以下配置正确：

cognitoUserPoolsTokenProvider.setKeyValueStorage(
  new CookieStorage({
    secure: process.env.NODE_ENV === 'production' // 生产环境必须启用 secure
  })
);

处理重定向时机

针对重定向问题，建议：

1. 不要立即在登录后重定向
2. 使用 Amplify 提供的 fetchAuthSession 方法检查认证状态
3. 添加适当的延迟或状态监听机制

浏览器兼容性注意事项

特别需要注意 Safari 等 WebKit 内核浏览器的特殊要求：

1. secure 属性必须为 true
2. 本地开发时可能需要配置 HTTPS
3. 生产环境强烈建议使用 HTTPS

最佳实践总结

1. 统一存储策略：明确配置存储方式，避免依赖默认行为
2. 流程完整性：理解并尊重 OAuth 2.0 的安全流程
3. 错误处理：为令牌存储和验证添加适当的错误处理和重试机制
4. 环境适配：区分开发和生产环境的配置
5. 状态管理：使用 Amplify 提供的状态监听机制而非直接检查存储

通过理解这些底层机制和正确配置，开发者可以构建更可靠的身份验证流程，同时满足安全性和用户体验的需求。