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

在 AWS Amplify 项目中，开发者有时会遇到外部身份提供商（如 Google）登录时令牌存储方式不符合预期的问题。本文将深入分析这一现象的原因和解决方案。

问题现象

当使用 AWS Amplify 进行身份验证时，开发者可能会发现：

1. 使用电子邮件/密码登录时，令牌能正确存储在 Cookie 中
2. 但使用 Google 等外部身份提供商登录时，令牌却暂时存储在 localStorage 中

技术背景

这种现象实际上涉及 OAuth 2.0 授权流程的安全机制：

1. PKCE 流程：现代 OAuth 实现通常使用 Proof Key for Code Exchange 机制来增强安全性。在重定向到身份提供商之前，客户端需要生成并存储一个临时的验证码（code_verifier）。

2. 临时存储需求：这个验证码需要在重定向前后保持一致，因此必须存储在客户端。由于 Cookie 可能受到跨域限制，localStorage 成为更可靠的选择。

解决方案

对于希望统一使用 Cookie 存储的开发者，可以采取以下措施：

1. 正确配置 CookieStorage：

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

2. 处理重定向时序：

• 由于 OAuth 流程中会先使用 localStorage 存储 PKCE 相关数据
• 应在检测到完整认证流程完成后再进行页面跳转
• 可以监听 auth 状态变化或检查完整的 token 集合

浏览器兼容性注意事项

特别是 Safari 浏览器有更严格的安全策略：

• 必须设置 secure: true 才能成功写入 Cookie
• 在开发环境中可能需要配置 HTTPS 才能测试完整流程

最佳实践建议

1. 在生产环境中始终使用 HTTPS 和 secure Cookie
2. 实现完整的认证状态检测逻辑，而不仅依赖存储介质检查
3. 考虑使用 Amplify 提供的 Auth 状态监听器，而不是直接检查存储

通过理解这些底层机制，开发者可以更好地处理外部身份提供商集成中的存储问题，构建更可靠的认证流程。