JWT访问令牌内存存储的实践困惑与相关疑问

这个方案到底怎么运作？ #

• Access Token在有效期内完全可以复用，不用每次请求都去生成新的。通常会把Access Token的过期时间设短（比如15~30分钟），在它没过期的这段时间里，所有需要鉴权的接口都直接用内存里的这个Token发请求就行。
• 只有当Access Token过期（比如接口返回401状态码），或者你提前检测到它快过期时，才会触发用Refresh Token刷新的流程：调用专门的刷新接口，后端会自动从Cookie里读取Refresh Token（不用前端手动传），验证通过后返回新的Access Token（一般还会附带新的Refresh Token，自动更新Cookie里的旧值），你把新的Access Token存回内存就可以继续使用了。

内存存Access Token的问题怎么解决？ #

• 页面刷新后内存里的Token确实会被清掉，但不用每次都重新登录。你可以在页面加载完成后，先检查Cookie里的Refresh Token是否存在，直接调用刷新接口获取新的Access Token，整个过程用户完全无感知，不需要重新输入账号密码。
• 内存存储的核心优势就是防XSS：恶意脚本没法直接读取内存里的变量，而如果存在localStorage里，脚本可以直接拿到Token做坏事。刷新时的Token刷新流程，是安全和用户体验之间的合理平衡。

为什么不能用localStorage存Access Token？ #

• 最大的问题就是XSS攻击风险：一旦你的页面被注入了恶意脚本，脚本可以通过localStorage.getItem()直接读取到Access Token，然后拿着这个Token冒充用户调用接口，只要Token没过期，恶意操作就能一直进行。
• 而存在Cookie里的Refresh Token，只要你设置了HttpOnly（禁止JS读取）、Secure（只在HTTPS下传输）、SameSite=Strict/Lax（防止CSRF）这些属性，XSS脚本根本碰不到它，安全性高太多。

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