Cookie、Session、Token 与 JWT：鉴权方案选型

HTTP 是无状态协议，"登录"本质是解决：服务器如何认出后续请求是你。

Cookie：浏览器的存储机制

Cookie 是浏览器存储小段数据并在同域请求自动携带的机制。服务器通过 Set-Cookie 下发。它本身不是鉴权方案，而是各种方案的载体。

关键属性：HttpOnly（JS 读不到，防 XSS 窃取）、Secure（仅 HTTPS）、SameSite（防 CSRF）、Expires/Max-Age。

Session：服务器存状态

经典方案：登录后服务器创建 Session（存在服务端内存/Redis），把 SessionId 通过 Cookie 发给浏览器。之后浏览器凭 Cookie 里的 id，服务器查 Session 确认身份。

• 优点：状态在服务端可控，可主动注销、可强制下线
• 缺点：服务端要存储、分布式下要共享 Session（Redis），对跨域和多端（原生 App）支持别扭

Token：无状态令牌

思路转变：登录后服务器签发一个令牌交给客户端，客户端之后每次请求带上（通常放 Authorization 头），服务器验签确认。状态不存服务器，天然适合分布式和跨端。

JWT：Token 的标准格式

JWT 是 JSON Web Token，结构为三段：Header.Payload.Signature，用点连接：

xxxxx.yyyyy.zzzzz
// Header：算法类型
// Payload：载荷数据（userId、过期时间 exp）—— Base64 编码，不是加密，谁都能读！
// Signature：用密钥对前两段签名，防篡改

服务器用密钥验签就知道令牌是否被伪造，无需查库。

但 JWT 有几个必须知道的坑：

1. 无法主动失效：有效期内服务端不存储，就没法让它提前过期——退出登录、修改密码后旧 token 仍有效。常见对策：短有效期 + Refresh Token，或维护黑名单（又变回有状态）
2. Payload 不要放敏感信息（Base64 可解码），只放 userId 之类
3. 体积比 SessionId 大，每次请求都带
4. 密钥必须保密且足够随机；算法选择要防 alg: none 攻击

现代推荐实践

• Web 应用：JWT 存 httpOnly + Secure + SameSite Cookie（而非 localStorage——防 XSS 直接窃取），兼顾 CSRF 防护
• 短 Access Token（分钟/小时级）+ 长 Refresh Token（可旋转、可吊销）
• 需要强会话管控（单点登录、踢人下线）→ Session + Redis 更简单可靠
• 权限实时变化频繁的系统不要迷信"纯无状态"

选型核心：先明确"注销/吊销是否必须立即生效""客户端是什么端""是否多服务共享认证"，再决定状态放哪。没有银弹，只有取舍。