认证要回答的问题只有一个：怎么证明这个请求是你发的。Cookie、Session、JWT 是三条主流路线，区别在状态存在哪、服务端要不要记东西。
三种机制怎么工作
Cookie 把数据存在浏览器，服务端每次从请求头里取；Session 只让浏览器存一个 ID，真正的会话数据放服务端（Redis/DB）；JWT 把用户信息和签名整个塞进 token 交给客户端，服务端验签通过就信任，什么都不存。
核心差异
| 特性 | Cookie | Session | JWT |
|---|---|---|---|
| 数据存储位置 | 客户端 | 服务端（Redis/DB） | 客户端（token 本身） |
| 服务端状态 | 无 | 有（集中存储） | 无 |
| 扩展性 | 天然无状态 | 需共享存储，分布式麻烦 | 天然支持分布式 |
| 能否主动失效 | — | ✅ 删 Session | ❌ 需黑名单等机制 |
| 典型场景 | 配合 Session 用 | 传统 Web、支付等强管控 | 无状态 API、微服务、跨域 |
Cookie 的三个安全属性
Set-Cookie: session_id=abc; Path=/; HttpOnly; Secure; SameSite=Strict
- HttpOnly：禁止 JS 读取，防 XSS 偷 Cookie；
- Secure：仅 HTTPS 传输，防明文嗅探；
- SameSite：控制跨站请求是否携带——
Strict只允许同站（银行类）；Lax允许安全跨站跳转（默认）；None允许所有跨站（必须配合 Secure）。
Session-Cookie 方案的攻防
| 攻击 | 防御 |
|---|---|
| Session 劫持 | 绑定客户端指纹（IP/UA）并校验 |
| Session 猜测 | 强随机 Session ID（≥128 位） |
| Session 固定 | 登录成功后重置 Session ID |
| XSS 窃取 Cookie | HttpOnly（JS 读不到） |
| 中间人嗅探 | Secure + 全站 HTTPS |
| CSRF | SameSite=Strict + CSRF Token |
JWT 的安全要点
JWT 的优势是服务端无状态、跨域友好。代价有两个：token 泄露后无法主动撤销；Payload 只是 Base64 编码不是加密，别放密码等敏感信息。做法是短有效期（15 分钟级）+ Refresh Token 续期，签名算法校验白名单防算法混淆攻击，token 优先放 HttpOnly Cookie 而不是 LocalStorage。
// Node.js 生成 JWT 示例
const jwt = require('jsonwebtoken');
const token = jwt.sign({ user_id: 123 }, 'secret_key', { expiresIn: '15m' });
如何选型
- 选 Session-Cookie：需要服务端严格管控会话（支付、风控）、传统单体或小型应用、需要主动踢人/改密立即可用；
- 选 JWT：无状态 API、微服务/Serverless、跨域认证（OAuth2 场景常见）；
- 两者可结合：现代方案常是”JWT 做身份 + 服务端黑名单兜底主动失效”或”短 token + refresh token”组合拳。
通用安全原则：最小权限（只放必要信息）、防御纵深（HttpOnly + Secure + SameSite 组合）、异常行为监控。
