JWT 和 Session 认证怎么选

JWT 和服务端 Session 都常用于登录后保持用户认证状态。区别在于，应用把信任状态放在哪里。

Session 主要把状态放在服务端。JWT 把签名后的声明放在 Token 自身里。

服务端 Session 怎么工作

Session 模式下，浏览器通常在 cookie 里保存一个不透明的 session ID。服务端再用这个 ID 去数据库、缓存或 session store 查询状态。

这种模式适合：

• 需要立即登出和撤销。
• 需要集中控制会话。
• 以浏览器 cookie 为主的认证。
• 客户端凭据尽量小。
• 角色变化由服务端统一管理。

代价是每个请求都需要访问 session 状态。

JWT 认证怎么工作

JWT 模式下，客户端发送一个签名 Token。API 验证签名后读取 subject、issuer、audience、expiration 等声明。

这种模式适合：

• 多服务共同消费的 API。
• 边缘层或服务层做无状态验证。
• 身份提供方签发短期 access token。
• 声明需要跨系统流转。
• 移动端或服务到服务认证。

代价是撤销和声明新鲜度需要仔细设计。

撤销是最大差异

Session 更容易撤销，因为状态由服务端持有。删除或失效 session 后，下一次请求就会失败。

长生命周期 JWT 更难撤销。常见缓解方式包括短 access token 生命周期、refresh token、token version 检查、高风险场景 deny list，以及在应用层重新检查权限。

浏览器应用经常混合使用

很多生产系统会组合两种模式：

• 浏览器持有 HTTP-only secure cookie。
• 后端保存 refresh 或 session 状态。
• API 接收短生命周期 JWT access token。
• 敏感授权仍然查服务端数据。

选择不总是二选一。

调试建议

JWT 流程里，可以用 JWT 解码器 查看声明，再用 时间戳转换器 检查 exp、iat、nbf。

Session 流程里，重点检查 cookie 设置、session store 可用性、domain/path 属性、SameSite 行为，以及服务端失效逻辑。

实用判断

当集中控制和浏览器简单性最重要时，优先 Session。当签名声明需要跨 API 和服务流转时，考虑 JWT。无论哪种，都不要把秘密放进去，并且要明确验证每条信任规则。