jwt本身不提供认证，只是安全载体；服务端需严格签发（强密钥、合理exp、iat/nbf、最小权限）、安全存储（禁用localstorage，推荐httponly cookie）、完整校验（格式、签名、claims、用户状态），并叠加session绑定、二次验证等防护。
JWT身份验证的核心逻辑
JWT（JSON Web Token）本身不提供认证，它只是承载用户身份信息的安全载体。真正的身份验证发生在服务端：用户登录时校验账号密码，通过后生成JWT返回；后续请求携带该Token，服务端验证签名、有效期和内容后再放行。关键不是“用JWT”，而是“如何正确签发、传输和校验”。
安全签发JWT的必须操作
服务端生成Token时不能只填payload，必须严格控制以下几点：
- 使用强密钥 + HS256/RS256：避免用弱字符串（如"123"）或硬编码密钥；生产环境优先用RS256配非对称密钥，私钥仅服务端持有
- 设置合理过期时间（exp）：通常15–30分钟；敏感操作（如转账）应更短，甚至用一次性token
- 添加签发时间（iat）和可选的nbf（not before）：防止重放攻击和提前使用
- 写入用户唯一标识（如sub字段）和最小必要权限（scopes）：避免在token里塞密码、手机号等敏感字段
前端存储与传输的避坑要点
浏览器端存JWT绝不能用localStorage——XSS漏洞可直接盗取。推荐方案：
- HttpOnly + Secure + SameSite=Strict 的 Cookie：最安全，JS无法读取，自动随请求发送，但需后端配合设置
- 内存中临时保存（如React的useState）+ 手动带入Authorization头：适合单页应用，关闭标签页即失效，需配合刷新机制
- 禁用：localStorage/sessionStorage、URL参数、普通Cookie（无HttpOnly）
服务端校验不可省略的步骤
每次收到JWT都必须完整验证，缺一不可：
立即学习“Java免费学习笔记（深入）”；
- 解析前检查格式：确保是三段式（header.payload.signature），且base64url解码合法
- 验证签名有效性：用对应算法和密钥重新计算签名，比对是否一致
- 检查标准声明（claims）：exp是否过期、nbf是否生效、iss/aud是否匹配当前服务
- 验证用户状态：查数据库确认该用户未被禁用、令牌未被主动注销（需维护黑名单或短生命周期）
进阶防护建议
单纯依赖JWT不够，还需叠加其他机制：
- 登录成功后生成新Session ID并绑定IP/User-Agent（可选），异常变动时强制重新认证
- 敏感接口二次验证：如修改密码前要求输入短信验证码或当前密码
- 定期轮换签名密钥，并支持多密钥并存过渡（避免全部token瞬间失效）
- 记录登录日志和异常Token使用行为，用于风险识别
