Cookie、Session、Token、JWT 有什么区别？

详细解析#

四个概念不在同一个层面#

Cookie 的 HttpOnly、SameSite 等属性，以及它和其他存储方式的对比，见浏览器存储。

Session#

1. 用户登录，服务端校验通过，创建会话：sid=abc123 → { userId: 42 }
2. 响应头：Set-Cookie: sid=abc123; HttpOnly; Secure; SameSite=Lax
3. 之后的请求，浏览器自动带上：Cookie: sid=abc123
4. 服务端用 sid 查到会话，就知道是谁

有多台服务器时，Session 如果只存在某一台的内存里，请求落到其他机器上就会丢失登录态。常见做法是把 Session 集中存到 Redis；也可以让负载均衡做会话保持（见反向代理和负载均衡），但不如共享存储可靠。

Token 和 JWT#

Token 由客户端（浏览器、App）自己保存，请求时放在请求头里：Authorization: Bearer <token>。它不依赖 Cookie，跨域调用和移动端使用都方便。如果 Token 只是一个随机字符串，服务端仍然要查存储，本质上和 Session 差不多；JWT 则把信息直接放在令牌里。

JWT 由 Header、Payload、Signature 三部分组成，各自经过 Base64URL 编码后用 . 连接：

Header（签名算法和类型）
{"alg":"HS256","typ":"JWT"}

Payload（声明：用户 ID、角色、签发时间、过期时间等）
{"sub":"123","role":"user","iat":1760000000,"exp":1760000900}

Signature（用服务端密钥对前两部分签名）
HMAC-SHA256(base64url(Header) + "." + base64url(Payload), 密钥)

拼起来就是：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJyb2xlIjoidXNlciIsImlhdCI6MTc2MDAwMDAwMCwiZXhwIjoxNzYwMDAwOTAwfQ.sXNbzV73WCCUiui70nqvWmxRMDnbxUkoxd_WWHzKF9I

• 签名保证内容不被篡改：改了 Payload，签名就对不上
• Payload 只是编码，不是加密，任何人都能解码看到，不能放密码、手机号等敏感信息
• HS256 用同一个密钥签名和验证；RS256 等非对称算法用私钥签名、公钥验证，其他服务只拿公钥就能验证，适合跨服务
• 服务端校验时要检查签名和 exp，并限定允许的算法（比如只允许 HS256），防止攻击者篡改 Header 里的 alg 绕过校验

Session 和 JWT 对比#

双令牌：Access Token + Refresh Token#

• Access Token 有效期短（比如 15 分钟），每次请求都带上，泄露了损失也有限
• Refresh Token 有效期长（比如 7 天），只用来换取新的 Access Token；服务端通常会记录它，可以随时作废
• Access Token 过期后，接口返回 401，前端用 Refresh Token 调刷新接口换取新的 Access Token，再重试原请求；多个请求同时遇到 401 时，只刷新一次

令牌存在哪里#

XSS 和 CSRF 的原理见 XSS 和 CSRF。

面试官可能追问#

易错点#

• JWT 的 Payload 只是 Base64URL 编码，不是加密，不能放敏感信息
• Cookie 和 Token 不是对立的：Cookie 是载体，Token 也可以放在 Cookie 里。"用 Token 就没有 CSRF"的前提是令牌不放在 Cookie 里，而是由前端手动加到请求头上
• HttpOnly 只能防止令牌被脚本读走，防不了 XSS 脚本直接在页面里发请求