Session 认证在安全性上通常优于 JWT，因为敏感数据存储在服务端，客户端只持有 Session ID；JWT 将数据存在客户端，虽通过签名防篡改但内容可见，适合无状态扩展场景。
先说结论：Session 适合对安全性要求高、可控性强的单体或局域网应用，JWT 适合跨域、微服务等需要无状态扩展的分布式场景。
- 适合：金融、后台管理等敏感操作选 Session，移动端、微服务互联选 JWT。
- 重点看：JWT 载荷不可存敏感信息，Session 需防范 CSRF 攻击。
- 别忽略：JWT 撤销困难，需配合短有效期或黑名单机制。
快速处理思路
选型时先判断业务架构是否分布式，再评估数据敏感程度。若为单体应用且涉及敏感信息，优先 Session；若为微服务且需跨域通行，优先 JWT 并配置 HTTPS 与短过期时间。
为什么会这样
核心区别在于状态存储位置不同导致的安全边界差异。Session 将用户数据存储在服务器内存或 Redis 中，客户端仅持有无意义的 Session ID，即使 ID 泄露，攻击者无法直接获取用户信息且服务端可主动销毁会话。JWT 将用户信息编码在 Token 载荷中，客户端持有完整令牌，虽通过签名防止篡改，但载荷经 Base64 编码而非加密，任何人解码均可查看内容，且服务端无法主动失效已发出的令牌。
分步处理
实施认证方案时，按以下步骤加固安全性：
- 传输加密：无论 Session 还是 JWT，必须强制启用 HTTPS，防止中间人窃听。
- 存储安全：Session ID 建议存入 HttpOnly Cookie 防 XSS；JWT 若存 Cookie 需设 HttpOnly，若存 LocalStorage 需防范 XSS 脚本读取。
- 敏感数据：Session 可在服务端存任意数据；JWT 载荷严禁存密码、手机号等敏感信息。
- 有效期控制：Session 可设置闲置超时；JWT 必须设置较短过期时间（如 15 分钟），配合 Refresh Token 机制。
怎么验证是否生效
通过浏览器开发者工具检查存储与请求头。查看 Cookie 栏确认 Session ID 是否存在且标记为 HttpOnly；查看 LocalStorage 确认 JWT 内容；在网络请求头中检查 Authorization 字段是否携带 Token 或 Cookie 是否自动发送。尝试解码 JWT 载荷，确认无敏感明文信息。
常见坑
JWT 常被误用于存储敏感数据，导致信息泄露风险。Session 在分布式环境下若未共享存储（如 Redis），会导致用户登录状态丢失。JWT 撤销需引入黑名单或短有效期，否则被盗令牌在过期前一直有效。Cookie 存储需防范 CSRF，建议配合 SameSite 属性或 CSRF Token。
常见问题
JWT 被盗了怎么办？
无法直接撤销，只能等待过期或将其加入黑名单。建议设置较短的 Access Token 过期时间，并使用 Refresh Token 机制刷新。
Session 一定比 JWT 安全吗？
在数据保密性上是的，因为数据在服务端。但若 Session ID 被窃取且未设 HttpOnly，同样会被劫持，两者都依赖传输层安全。
分布式系统必须用 JWT 吗？
不一定，Session 配合 Redis 集中存储也能实现分布式共享，但会增加数据库读写开销，JWT 则无需查库验证。
参考来源
- Token(如 JWT) 与 Session 相比，在安全性、扩展性方面有何优劣？ (2026 年 3 月 31 日)
- Session 与 JWT 安全对比 (2025 年 9 月 26 日)
- 用户认证：基于 JWT 和 Session 的区别与优缺点 (2024 年 2 月 19 日)
- JWT 认证和 Session 认证区别 (2024 年 11 月 21 日)