JavaScript 中怎么将传统的基于 Session 的认证迁移到无状态的 JWT 方案-js教程-PHP中文网

jwt迁移核心是将用户状态从服务端转至客户端token，前端改用localstorage存token并带bearer头请求，后端改验签名与时间戳，需引入refresh token机制处理过期，并强化https、敏感操作二次验证及黑名单等安全措施。

javascript 中怎么将传统的基于 session 的认证迁移到无状态的 jwt 方案

将传统 Session 认证迁移到 JWT，核心是把服务端“记住用户”的责任，从服务器内存或数据库（Session 存储）转移到客户端 Token 本身，并通过签名保证不可篡改。

1. 前端登录流程要改：用 JWT 替代 Cookie 写入

原来登录成功后，后端 set-cookie 写入 Session ID；现在登录成功后，后端返回一个 JWT 字符串（如 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... ），前端需主动存起来——推荐用 localStorage 或 sessionStorage（注意 XSS 风险），不再依赖浏览器自动携带 Cookie。

后续每次请求（尤其是受保护接口），在 Authorization 请求头中带上：Bearer <your-jwt-token></your-jwt-token>
前端路由守卫（如 Vue Router 的 beforeEach、React 的自定义 Hook）需检查本地是否有有效 Token，没 token 或过期则跳转登录页
避免把敏感信息（如密码、权限列表）直接塞进 JWT payload，只放必要标识（如 userId、role），权限校验仍应在后端做

2. 后端验证逻辑要重写：不查 Session，只验 Token

原来中间件（如 Express 的 session()）会根据 Cookie 中的 Session ID 查 Redis 或数据库；现在要换成 JWT 验证中间件：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

从 Authorization 头提取 Token，用相同密钥（secret 或公私钥）验证签名是否有效
检查 exp（过期时间）、nbf（生效时间）等标准字段，拒绝过期或未生效 Token
验证通过后，把 payload 中的用户信息（如 userId）挂到 req.user 上，供后续业务逻辑使用
不再调用 req.session.destroy()，登出只需前端清除本地 Token 即可（严格来说，JWT 本身无法“主动失效”，需配合黑名单或短生命周期 + 刷新机制）

3. 处理 Token 过期与刷新：不能只靠延长 exp

JWT 一旦签发就不可更改，所以不能像 Session 那样“续期”。常见做法是引入 Refresh Token：

登录时，后端同时下发 Access Token（短时效，如 15 分钟）和 Refresh Token（长时效，如 7 天），后者通常存于 httpOnly Cookie 或安全存储中
Access Token 过期时，前端用 Refresh Token 向 /refresh 接口换新 Access Token，后端验证 Refresh Token 合法性并生成新 Token
Refresh Token 应绑定设备/指纹，且每次使用后作废（或滚动更新），防止被盗用