Next.js如何实现JWT SSR鉴权 替代本地存储Token方案

完全可行，核心方案是把Token存储从localStorage迁移到HttpOnly Cookie，整个鉴权逻辑前置到SSR渲染阶段完成，具体实现流程如下：

• 调整后端Token下发逻辑
  后端完成用户登录校验后，不再把access token、refresh token放在响应体中返回给前端，而是直接通过Set-Cookie响应头写入两个带安全属性的Cookie：

  • access_token：标记HttpOnly、Secure（生产环境必须开启）、SameSite=Lax/Strict，过期时间和access token本身有效期对齐
  • refresh_token：同样配置HttpOnly、Secure、SameSite属性，过期时间和refresh token有效期对齐，单独设置Path为刷新Token的专用接口路径，避免普通接口请求不必要携带该Cookie
    配置HttpOnly属性后，前端JS无法读取这两个Cookie，既不需要操作localStorage，也能从根源避免XSS攻击窃取Token的问题。

• SSR层鉴权处理逻辑
  用户每次访问页面时，SSR服务端可以直接从入站请求的请求头中拿到浏览器自动携带的Cookie，解析出access token做校验：

  • access token有效：直接携带该Token拉取页面所需的用户态数据，渲染完整的有权限页面返回给客户端，不需要额外在客户端做登录态判断弹窗
  • access token过期/不存在：SSR服务端直接向后端发起Token刷新请求，同域请求会自动携带refresh_tokenCookie，拿到新的access token后重新写回Cookie，再走正常页面渲染流程
  • refresh token也过期/不存在：SSR服务端直接返回重定向响应跳转到登录页，或者直接渲染“仅面向注册用户提供服务”的提示页，不需要等客户端JS加载完成后再弹提示。

• 客户端请求适配
  客户端侧发起接口请求时，不需要手动从存储里取Token拼接请求头，只要给请求配置携带凭证参数：fetch请求加credentials: 'include'，axios请求加withCredentials: true，浏览器会自动把对应域名下的合法Cookie带到请求头中传给后端。如果接口返回401状态码，客户端直接触发页面重载即可，Token刷新逻辑全部交给SSR层处理。

注意：如果你的SSR服务和后端接口服务不在同一个根域名下，需要提前配置跨域规则：接口端需要设置Access-Control-Allow-Credentials: true，同时Access-Control-Allow-Origin不能配置为通配符*，必须明确指定允许的前端域名，否则Cookie无法正常跨域携带。

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