为何在客户端存储Access Token与Refresh Token存在安全风险？及安全方案解析

一、浏览器/移动设备存储Access Token与Refresh Token的安全风险 #

• XSS攻击易窃取令牌：如果把令牌存在浏览器的localStorage/sessionStorage里，一旦页面遭遇XSS攻击，恶意脚本能直接读取这些令牌，冒充用户发起各类授权请求；移动设备中的WebView若存在漏洞，也会被恶意代码钻空子偷走令牌。
• CSRF攻击隐患：若令牌存在Cookie且未配置HttpOnly，跨站请求会自动携带Cookie，攻击者可构造恶意页面诱导用户点击，发起未授权操作；就算设置了HttpOnly，SameSite属性配置不当的话，仍可能遭遇CSRF攻击。
• 本地存储泄露风险：移动设备丢失或被Root/越狱后，攻击者能直接读取本地存储的令牌；浏览器本地存储的数据也可能通过物理接触设备、恶意插件等方式被窃取。
• 令牌劫持与冒用：若传输令牌时未使用HTTPS，容易被中间人攻击劫持；而且令牌一旦被获取，攻击者能长期冒用用户身份，直到令牌过期。

二、图示BFF架构方案的安全性说明 #

图示的是Backend for Frontend（BFF）架构，这是目前公认的前端身份认证安全方案，核心是把令牌的存储和管理完全交给后端服务，前端仅持有一个安全的会话Cookie，具体安全优势如下：

• 令牌完全脱离前端环境：Access Token和Refresh Token都存储在BFF服务端（比如内存或加密存储介质），前端根本接触不到真实令牌，从根源上杜绝了XSS、本地存储泄露等前端层面的风险。
• 会话Cookie的强安全配置：前端持有的会话Cookie会设置HttpOnly（禁止JS读取）、Secure（仅HTTPS传输）、SameSite=Strict（阻止跨站请求携带），把CSRF和XSS窃取Cookie的概率降到最低。
• 令牌流转全受控：所有需要调用上游服务的请求，都由BFF代为转发，BFF负责在请求中带上Access Token；前端仅需用会话Cookie和BFF验证身份，无需处理令牌刷新、过期等逻辑，也避免了令牌在前端传输、存储的环节。
• 额外的安全校验层：BFF可作为中间层，对前端请求做额外校验，比如验证请求来源、会话状态，还能进行权限过滤，进一步提升整体安全性；同时令牌刷新由BFF自动处理，前端无感知，减少了令牌泄露的场景。

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