JWT 的原理、流程与安全实践

Authorization: Bearer <token>

5. 服务端验证签名和过期时间，通过就放行，不通过就返回 401 Unauthorized。

Session 和 JWT 的差别

两者都能做认证，但思路完全不同。

JWT 不是更高级，只是更适合某些场景。状态少了，部署和扩展会轻松很多；代价是注销、续期和安全控制都要自己补上。

JWT 的安全实践

很多 JWT 的问题，根子不在协议，而在用法。

1. 一定走 HTTPS

Token 本质上就是一段可携带身份信息的字符串，明文传输被截获，攻击者就能直接冒用。这个没什么可商量的，全站 HTTPS 是底线。

2. 算法别乱选

• HS256：对称加密，签发和验证用同一个 Secret。实现简单，适合单体应用。
• RS256：非对称加密，私钥签发、公钥验证。更适合认证中心和多个业务服务分离的架构。

3. 存储位置要想清楚

JWT 放哪儿，往往比'用不用 JWT'更容易出问题。

• LocalStorage：前端使用方便，但一旦有 XSS，Token 很容易被读走。
• HttpOnly Cookie：JS 读不到，能挡住很多 Token 被直接窃取的场景；但要面对 CSRF，跨域处理也更绕一点。

如果安全要求高，我会优先考虑 httpOnly 和 Secure Cookie。它不一定最省事，但通常更稳。

4. 处理注销和续期

JWT 最大的现实问题是：签出去以后，不容易撤回。用户改了密码、账号被封、手动注销，这些动作都不会自动让旧 Token 立刻失效。

常见做法有两种：

• 黑名单机制：把注销后的 Token ID 放进 Redis，并设置和 Token 一样的过期时间。校验时顺手查一下黑名单。严格来说这已经不是纯无状态了，但在安全和可控性之间算是比较实用的折中。

• 双 Token 机制：

  • Access Token：有效期短，比如 15 分钟，用来访问接口。
  • Refresh Token：有效期长，比如 7 天，用来换新的 Access Token。

  这样做的好处是，Access Token 过期后可以平滑续期；如果用户注销，只要让 Refresh Token 失效就行，Access Token 最多再活一小段时间。

什么时候用 JWT

JWT 适合这些场景：

• 微服务架构
• 前后端分离
• 移动端应用
• 不希望服务端长期保存会话状态的系统

不太适合这些场景：

• 对注销、踢下线、强控制要求特别高的系统
• Token 内容很大、请求头开销已经开始影响性能的场景

JWT 不是银弹。它解决的是'怎么少存状态'，不是'所有认证问题都交给它'。把它放在合适的位置，配上 HTTPS、合理的存储方式和过期/续期策略，才算真的能用。