React应用中JWT令牌校验时机及安全问题咨询

核心结论 #

你当前的实现存在明确安全隐患，不符合生产环境安全要求；路由切换时不需要每次都发请求到服务端全量校验JWT，但必须做分层校验，完全跳过路由侧校验的逻辑是错误的。

当前实现的具体安全风险 #

• 认证状态与实际权限脱节
  你把JWT校验逻辑仅放在AuthContext挂载时执行，意味着整个应用生命周期（从打开页面到刷新/关闭页面）只会做一次服务端校验。如果出现用户账号被封禁、用户主动登出其他设备、用户权限被调整（比如从管理员降级为普通用户）、JWT被加入服务端黑名单的场景，前端完全感知不到状态变化：用户依然可以看到对应权限的菜单、访问受保护路由，直到手动刷新页面。如果部分业务接口漏加服务端鉴权逻辑，会直接出现未授权访问的漏洞。
• 基础Cookie配置缺失带来的通用风险
  你将JWT存储在Cookie中且设置了5天超长有效期，如果没有配置HttpOnly、Secure、SameSite属性，会直接暴露在XSS令牌窃取、CSRF跨站请求伪造的攻击路径下：攻击者一旦拿到有效期5天的JWT，可以完全冒用用户身份直到令牌自然过期。
• 权限控制边界模糊
  前端校验逻辑只在初始化执行，路由层无任何拦截，等于把所有权限控制的压力全压在业务接口上，一旦某个接口漏写鉴权逻辑，没有前端路由层的第一道拦截，很容易出现越权漏洞。

正确的校验逻辑设计 #

JWT本身是自包含的签名凭证，不需要每次路由跳转都发请求到服务端做全量校验，只需要做两层校验即可平衡性能和安全：

1. 路由层轻量本地校验（无接口请求）
   不要把校验逻辑只放在AuthContext的挂载钩子中，封装统一的受保护路由组件（适配你用的react-router版本即可），每次路由跳转时执行本地校验：
   • 检查存储JWT的Cookie是否存在
   • 本地解码JWT的payload部分（payload仅做base64编码，无加密），检查exp字段标识的过期时间是否已超时
   • 对比JWT中携带的用户角色、权限标识，判断当前用户是否有目标路由的访问权限
     校验不通过直接重定向到登录页或403页面，这一步性能损耗可以忽略，能覆盖绝大多数未登录、令牌过期、无权限的场景，优化用户体验。
2. 服务端强制校验（唯一安全边界）
   前端的所有校验都只是体验优化，绝对不能作为安全判断依据。你需要在ASP.NET Core中配置全局JWT鉴权中间件，所有需要鉴权的业务接口统一走中间件校验：验证JWT签名合法性、是否过期、是否在失效黑名单中（如果需要支持主动登出、账号封禁等能力，把失效的JWT唯一标识jti存在Redis中，过期时间和JWT有效期一致即可），校验不通过直接返回401/403状态码。
3. 全局响应拦截兜底
   在你封装的请求客户端（axios等）中加全局响应拦截，只要收到服务端返回的401状态码，直接清空本地认证状态，跳转到登录页，覆盖令牌中途失效的场景。

额外优化建议 #

• 调整Cookie安全配置：写入JWT的Cookie必须开启HttpOnly: true禁止前端JS读取，开启Secure: true仅在HTTPS环境下传输，配置SameSite = SameSiteMode.Lax阻断CSRF攻击路径。
• 不建议使用单JWT长有效期的方案：5天有效期的令牌被窃取后风险敞口太大，建议替换为「短有效期access_token（2小时左右）+ 长有效期refresh_token（7天左右）」的双令牌机制，access_token存在内存中，refresh_token开HttpOnly Cookie存储，access_token过期后用refresh_token静默续期，大幅降低令牌泄露后的可用窗口。

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