单页应用中如何保护AWS Cognito生成的refresh_token？

核心前提：浏览器端的SPA不存在能完全免疫XSS的前端持久化存储方案，所有优化本质都是提升攻击成本、缩小风险敞口，没有银弹。

优先级最高的方案：将Refresh Token逻辑下沉到BFF层（推荐） #

这是目前OAuth2.1规范针对公开客户端SPA推荐的标准实践，能从根源上避免前端接触Refresh Token：

• 不要把Cognito的授权回调地址直接指向SPA前端路由，改为指向你自己部署的同域BFF服务接口
• BFF服务端承接Cognito的授权码回调，在服务端完成code + PKCE换token的全流程，拿到三类token之后，绝对不要把refresh_token返回给前端
• refresh_token直接存在BFF侧的服务端存储（加密Redis、落库加密存储都可以），access_token和id_token可以通过服务端Set-Cookie种短时效（和access_token有效期一致，通常10-15分钟）的HttpOnly; Secure; SameSite=Strict Cookie给前端，前端不需要手动读Cookie带鉴权头，BFF转发业务请求时自动把access_token注入请求头即可
• 后续access_token过期时，刷新逻辑完全由BFF侧闭环：BFF检测到access_token失效，自动用服务端存储的refresh_token向Cognito申请新token，整个过程前端无感知，也接触不到refresh_token
• 额外收益：你可以在BFF层自定义refresh_token的轮换、异常访问吊销、登录态强踢逻辑，不受Cognito控制台配置限制；就算前端站点出现XSS漏洞，攻击者最多拿到剩余有效期极短的access_token，完全拿不到可长期生效的refresh_token，风险窗口被压缩到最小。
• 针对Cognito的优化：你可以把对接BFF的Cognito客户端改成机密客户端，配置client_secret存在BFF服务端，进一步降低授权码泄露后的token被冒领的风险。

退而求其次：无后端纯静态SPA的风险收敛方案 #

如果你的项目是纯静态部署、完全没有服务端支撑，没法搭BFF，就从降低攻击收益、提升攻击成本的角度做多层防护：

• 绝对不要把refresh_token存在localStorage、sessionStorage，也不要存在主线程的全局变量里：把refresh_token放到Web Worker的内存中存储，主线程和Worker之间仅通过postMessage完成token读取、刷新的通信，XSS脚本要窃取token需要额外注入Worker、监听跨上下文通信，攻击成本远高于直接读本地存储
• access_token同样只存在内存中，页面刷新后如果需要恢复登录态，可以配合一个短时效（和access_token有效期一致）的Secure; SameSite=Lax非HttpOnly Cookie存id_token做态校验，这个Cookie时效要尽可能短，就算被XSS窃取也会快速失效
• 严格配置CSP响应头，禁止内联脚本执行、禁止未授信域名的脚本资源加载，从根源上降低XSS漏洞被利用的概率——不要迷信任何前端存储方案的防XSS能力，CSP是浏览器端XSS防御的核心防线
• 在Cognito控制台把refresh_token的有效期尽可能设短（建议1-7天，不要设成几十天的长时效），同时开启Cognito的Refresh Token轮换功能：每次用refresh_token换新token对之后，旧的refresh_token会自动失效，就算token被窃取，可用周期也会被大幅压缩。

常见避坑提醒 #

别信"用HttpOnly Cookie存refresh_token就安全"的错误说法：如果是Cognito直接回调到前端静态页面，token会通过URL fragment或参数直接返回给前端JS，这时候你只能用JS操作写Cookie，JS写的Cookie没法加HttpOnly属性，JS本身就能读到Cookie内容，等于完全没做防护。只有服务端接收到Cognito的token响应、通过服务端Set-Cookie头种下的HttpOnly Cookie，前端JS才无法读取，才能起到隔离作用。
你在Cognito控制台找不到关闭refresh_token返回的配置是正常现象：Cognito针对公开客户端（SPA类无client_secret的客户端）的授权码流默认强制返回refresh_token，没有提供关闭开关，不用浪费时间找配置。

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