多SPA系统认证方案选型：BFF、JWT优化还是传统会话？

核心选择理由 #

1. 安全达标且适配场景 #

• Access Token仅存在React应用的内存变量中（比如React Context或状态管理库的内存存储区），不会被XSS攻击窃取，规避了sessionStorage/localStorage的存储风险；页面刷新后内存Token丢失可通过Refresh Token自动恢复，不影响用户体验。
• Refresh Token存入HTTP-only Cookie，前端JS无法读取，从根源避免XSS窃取；同时给Cookie配置SameSite=Strict/Lax、Secure（HTTPS环境）属性，可有效防范CSRF攻击。授权服务器还可额外绑定用户Agent或IP信息验证Refresh Token，进一步提升安全性。

2. 开发维护成本极低（适配2人团队） #

无需改动现有核心架构，仅需少量调整：

• 授权服务器：返回Refresh Token时，将其设置为HTTP-only Cookie，配置Cookie的Domain=.domain.com（支持所有子域名SPA共享）、SameSite、Secure属性。
• React前端：登录成功后将Access Token存入内存，封装API请求拦截器，当Access Token过期时自动调用授权服务器的刷新接口（Cookie会自动携带Refresh Token），静默获取新的Access Token并更新内存值，全程无需用户操作。
  完全避免了BFF的重复开发工作量，也不用重构为服务器端会话架构。

3. 彻底解决用户体验痛点 #

Access Token每3小时过期后，通过Refresh Token静默刷新，用户无感知；页面刷新导致内存Token丢失时，也能自动触发刷新流程，除非Refresh Token过期，否则用户无需手动重新登录。

其他方案排除逻辑 #

方案1（BFF模式） #

每个SPA都需要开发专属代理后端，2人团队的代码量、维护压力远超当前承载能力，且无扩招预算，短期内无法落地，直接排除。

方案3（传统服务器端会话） #

现有资源服务器遵循无状态设计，改为服务器端会话需引入分布式会话组件（如Redis），大幅增加架构复杂度和运维成本，违背当前的DDD、整洁架构原则，排除。

实施关键注意事项 #

• 所有环境必须启用HTTPS，强制开启Cookie的Secure属性；
• 给Refresh Token设置合理过期时间（比如7天），授权服务器需支持Refresh Token主动失效机制（如用户登出时销毁）；
• React端严格禁止将Access Token持久化到localStorage/sessionStorage，仅在内存中维护；
• 授权服务器的刷新接口需添加限流策略，防范恶意刷新攻击。

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