Session 认证和 JWT 认证如何选择？

简化版

Session 认证：登录状态存在服务端，客户端只拿一个 session id（放 Cookie）。JWT 认证：身份信息编码进一个自包含的 token 放客户端，服务端靠签名验证、不存状态。核心权衡是**「可控性」vs「无状态」：Session 服务端可控——退出登录、踢人、权限变更能立即生效**，但集群要共享会话（Redis）；JWT 无状态——跨服务/移动端验证方便、不用查会话存储，但签发后到过期前难以撤销。选择：管理后台、强风控用 Session；开放 API、微服务、移动端常用 JWT——看架构和撤销需求，不是追新。

详细版

Session vs JWT 对比：

维度	Session	JWT
状态位置	服务端（客户端只存 session id）	客户端（token 自包含身份）
服务端存储	需要（内存/Redis）	不需要（无状态验证）
撤销/踢人	立即生效（删服务端会话）	难（要黑名单/version/短过期）
集群扩展	要共享会话（Redis）或粘性路由	天然无状态、易扩展
跨服务/跨域	较麻烦	方便（带 token 即可）
泄露风险	session id 泄露可踢会话止损	token 泄露到过期前一直有效
适用	管理后台、传统 Web、强风控	开放 API、微服务、移动端

两者都需要的安全基础：HTTPS、合理过期、防 XSS/CSRF。

完整版教学

一、状态保存在哪里（本质区别）

Session 模式：登录状态（用户是谁、权限）保存在服务端（内存或 Redis），浏览器的 Cookie 里只有一个 session id。每次请求服务端拿 session id 查会话，得到用户信息。
JWT 模式：身份声明、过期时间等信息编码进 token 本身，放在客户端。服务端验证 token 签名后就相信里面的声明，不需要查任何存储。

「状态存服务端」vs「状态存客户端」——这个根本区别，派生出后面所有的扩展性和安全权衡。

维度	Session	JWT
状态位置	服务端会话存储	客户端 token
每次请求	查 session id 对应会话	本地验签和校验声明
立即撤销	删除会话即可	需要黑名单、版本或短过期
扩展代价	Redis/粘性会话	撤销与状态同步复杂

选 Session 还是 JWT，本质是在“服务端可控性”和“无状态扩展性”之间做取舍。

二、Session 的优势：服务端可控

Session 最大的优势是服务端完全掌控会话，所以以下操作能立即生效：

用户退出登录 → 删除服务端会话，token 立刻失效。
管理员踢人下线 → 删对应会话即可。
权限变更、风险封禁 → 下次请求查会话时就能反映最新状态。

对管理后台、强风控系统、传统 Web 应用来说，这种「随时能撤销、能踢人、能实时反映权限变化」的可控性非常重要——这些场景往往有严格的安全和合规要求。

三、Session 的集群问题

Session 的代价是扩展性：多实例部署时，请求可能打到不同机器，而会话存在某一台的内存里（见「Cookie vs Session」专题）。解决方案：

粘性会话：负载均衡把同一用户固定到同一机器（简单，但机器挂了会话丢）。
集中式 Session 存储（Redis）：会话存 Redis，所有机器共享（主流）。要考虑过期策略、序列化兼容、Redis 故障时的降级。
让应用无状态（改用 JWT）。

所以 Session 在分布式下并非不能用——Redis 集中式 Session 是成熟方案，只是多了一个共享存储的依赖。

四、JWT 的优势：无状态、跨服务

JWT 适合 API 网关、微服务、移动端、跨域调用 的场景：

本地验证签名，不查会话存储：资源服务拿到 token，本地验签 + 校验声明就知道用户是谁，不用每次请求都去查 Session——省了一次存储访问，性能和扩展性好。
跨服务传递方便：请求带着 token 在微服务间流转，每个服务都能独立验证。
配合非对称密钥：授权服务持私钥签发，多个资源服务只需公钥验证——认证中心和资源服务解耦。

这些正是微服务/开放平台需要的特性——无状态带来的扩展性和跨服务能力。

五、JWT 的难点：撤销

JWT 的核心难点是撤销：token 一旦签发，在过期前天然有效。当用户退出、改密码、权限被收回、被封禁时，如果没有额外机制，旧 token 仍然能访问——这是 JWT 无状态的代价。

补救手段（本质是「给无状态加回一点状态」）：

短过期时间 + Refresh Token 轮换（缩小泄露/失效窗口，见 JWT 专题）。
黑名单（把要撤销的 token id 记下来，验证时查——但这又引入了状态和查询）。
token version / 权限版本（token 里带版本号，和数据库比对，版本变了则失效）。
高风险操作实时查库。

access token = 15 分钟有效
refresh token = 7 天有效 + 每次刷新轮换
用户被封禁 -> 提升 tokenVersion 或撤销 refresh token family

关键认知：JWT 不是「不用状态」，而是把状态管理问题「换了形态」——你以为省了 Session 存储，但为了撤销又得加黑名单/version。要清楚这个权衡，别以为 JWT 就完全无状态无负担。

六、安全存放与传输

无论 Session 还是 JWT，都必须走 HTTPS（防窃听）。客户端存储：

浏览器：Cookie 要 HttpOnly + Secure + SameSite（防 XSS 读取、防 CSRF）。把 token 放 localStorage 容易被 XSS 偷（JS 能读 localStorage，但读不了 HttpOnly Cookie）。
移动端：用系统安全存储（Keychain/Keystore）。

Session 的 session id 和 JWT 的 token 一样，泄露了都危险——但 session id 泄露可以「踢会话」止损，JWT 泄露到过期前难止损（除非有黑名单）。

七、选择建议

服务端渲染的 Web / 管理后台 → 优先 Session（可控、能踢人、实时权限）。
开放 API、移动端、跨服务认证 → 可选 JWT（无状态、跨服务）。
高安全场景 → 常组合使用：短命 access token（JWT）+ 可轮换的 refresh token + 服务端撤销记录——用短过期缩小 JWT 撤销难题，用服务端记录兜底强撤销。

别追潮流——很多系统用 Redis Session 已经足够稳定可控，JWT 的「无状态」优势只在真正需要跨服务/无状态时才值得它带来的撤销复杂度。

八、常见误区与追问

误区：JWT 一定比 Session 更先进。 JWT 适合无状态和跨服务，但撤销复杂；管理后台和强风控场景 Session 往往更合适。
误区：用了 JWT 就完全不需要服务端状态。 黑名单、token version、refresh token 轮换和撤销记录都会把部分状态加回来。
误区：Session 在集群中不能用。 Redis 集中式 Session 是成熟方案，只是增加共享存储依赖和可用性设计。
追问：为什么 Session 踢人能立即生效？ 登录态在服务端，删除对应会话后 session id 再请求就查不到有效状态。
追问：JWT 泄露后为什么更难止损？ token 在过期前可本地验签通过，除非引入黑名单、版本校验或缩短有效期。
追问：浏览器里 token 为什么不推荐放 localStorage？ localStorage 可被 JavaScript 读取，一旦 XSS 成功就容易被偷；HttpOnly Cookie 能降低读取风险。

九、加强记忆

Session：状态存服务端（客户端只存 session id），服务端可控——退出/踢人/权限变更立即生效，适合管理后台/强风控/传统 Web；代价是集群要共享会话（Redis 集中式，成熟方案）。JWT：身份编码进 token 存客户端，无状态验证（本地验签不查存储、跨服务方便、非对称密钥解耦），适合开放 API/微服务/移动端；难点是撤销（签发后到过期前难失效，退出/改密/封禁靠短过期+refresh 轮换/黑名单/version/实时查库补救——JWT 不是不用状态，而是把状态换了形态）。两者都要 HTTPS + Cookie（HttpOnly/Secure/SameSite，别放 localStorage）。选型看撤销需求、集群、客户端形态、风控，不是追新（Redis Session 常已够用）。

简化版

详细版