基于React和.NET 6的JWT认证：令牌存储与刷新等问题咨询

1. 令牌存储方案选择 #

优先级推荐：HttpOnly Cookie 存 Access Token + LocalStorage 存 Refresh Token > 内存存储（Redux） > LocalStorage 存 Access Token + HttpOnly Cookie 存 Refresh Token #

各方案优缺点明细：

• HttpOnly Cookie存Access Token + LocalStorage存Refresh Token
  • 优势：高频使用的Access Token被HttpOnly Cookie保护，完全规避XSS窃取风险；请求时浏览器自动携带Cookie，前端无需手动处理令牌逻辑，减少出错概率。
  • 劣势：Refresh Token存在LocalStorage，有XSS窃取风险，一旦被盗，攻击者可持续刷新获取新令牌。可通过给Refresh Token绑定用户IP、设备指纹等方式降低风险。
• LocalStorage存Access Token + HttpOnly Cookie存Refresh Token
  • 优势：仅Refresh Token安全，但Access Token是核心业务令牌，存在LocalStorage极易被XSS窃取，攻击者拿到后可直接调用敏感接口，危害极大。
  • 劣势：前端每次请求需手动将Access Token放入Authorization: Bearer xxx请求头，代码冗余且易遗漏；XSS攻击后直接导致用户权限被冒用，风险远大于收益。
• 内存存储（Redux状态）
  • 优势：完全避免XSS窃取，令牌仅存在内存中，页面刷新或关闭即消失，安全性拉满。
  • 劣势：页面刷新后令牌丢失，用户必须重新登录，体验极差；仅适合对安全性要求极高、允许会话级登录的场景（如银行类应用），普通业务应用不推荐。

2. JWT 刷新时机与触发方式 #

刷新时机：过期前主动刷新 #

推荐在Access Token过期前5-10分钟发起刷新请求，后端验证当前未过期的Access Token和Refresh Token有效性后，返回新的Access Token和Refresh Token（启用令牌轮换）。这种方式能避免用户操作时遇到401错误，体验更流畅。
若等Access Token过期后再刷新，用户发起的请求会返回401，虽可在前端拦截后刷新令牌并重试，但会出现短暂加载延迟或错误提示，体验不如主动刷新。

触发方式：定时器为主，401兜底 #

• 定时器触发：登录成功后，根据令牌过期时间计算刷新节点，设置全局定时器，到点自动发起刷新请求。注意加全局锁避免多个组件同时触发刷新，导致重复请求。
• 401兜底：作为备选方案，前端拦截所有请求响应，若遇到401状态码，先尝试刷新令牌，成功后重试原请求。主要应对定时器失效（如用户长时间离开页面，定时器被浏览器休眠）的场景。

后端刷新端点需支持两种逻辑：一是验证未过期的Access Token+Refresh Token；二是当Access Token过期时，仅验证Refresh Token合法性（只要Refresh Token有效，就返回新令牌）。

3. 用户数据与令牌过期时间获取 #

用户数据获取 #

登录成功后，后端在设置HttpOnly Cookie的同时，直接在响应体中返回用户信息（用户名、角色等），前端将这些数据存入Redux或LocalStorage（非敏感数据）即可，无需从JWT中解析。

令牌过期时间（exp、jti）获取 #

• 登录响应体返回：在登录接口的响应体中，除用户信息外，额外返回exp（过期时间戳）、jti等令牌元数据，前端存储这些值用于设置刷新定时器。
• 自定义响应头返回：后端在Set-Cookie的同时，通过自定义响应头（如X-Access-Token-Expires、X-Refresh-Token-Jti）返回这些信息，前端通过response.headers.get('X-Access-Token-Expires')读取。
• （不推荐）单独接口获取：若上述两种方式无法实现，可做一个轻量的令牌状态接口（如GET /api/auth/status），后端验证Cookie中的Access Token后，返回过期时间等信息。但这种方式多一次请求，效率低于前两种。

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