后端使用amazon-cognito-identity-js实现Cognito会话无localStorage持久化问询

会话持久化现象原因 #

你观察到的“无需前端存储令牌即可实现会话持久化”的现象，确实是因为该库部署在后端、会话数据全部存储在服务端导致的，核心逻辑如下：

• amazon-cognito-identity-js原生为前端设计，默认会将idToken、accessToken、refreshToken存储在浏览器localStorage中；当运行在Node/Express后端环境时，浏览器环境API不存在，库的存储逻辑会自动适配服务端环境，默认存在内存中，也可根据你的配置写入Redis、服务端Session等持久化存储介质
• 你的前后端交互应该是通过服务端下发的HttpOnly Cookie存储的会话ID关联，前端不需要接触Cognito返回的令牌，自然不需要在localStorage中存储任何认证相关内容

该实现方案的合理性评估 #

这个方案有明确的优势，但也存在需要注意的局限性，整体属于可行但需要做好配套设计的方案：

优势 #

• 安全性更高：Cognito令牌全程保留在服务端，前端完全无法获取，从根源上避免了XSS攻击窃取令牌的风险，比前端存储令牌的方案安全等级更高
• 认证逻辑统一收敛：令牌刷新、权限校验、过期处理逻辑全部在后端实现，前端不需要处理复杂的认证生命周期，降低前端逻辑复杂度
• 适配性更强：可无缝对接小程序、App等不支持托管前端认证逻辑的端侧，统一全端认证入口

需规避的问题 #

• 该库没有官方的后端运行适配，默认的内存存储只适合单实例调试场景，多实例部署时必须自行配置共享存储（比如Redis）存储Cognito会话，否则会出现会话漂移问题
• 库内置的前端自动令牌刷新逻辑在后端环境不生效，需要自行实现令牌过期判断、refreshToken换领新令牌的逻辑
• 方案会破坏服务的无状态性，增加了服务端存储开销，不适合纯无状态的服务架构
• 如果后续需要对接Cognito托管UI、社交登录等前端特性，会增加对接成本

内容的提问来源于stack exchange，提问作者Andy Harmuth