从“记住我”到 Web 认证：Cookie、JWT 和 Session 的故事

本文链接：https://blog.youkuaiyun.com/m0_70871140/article/details/145915461

文章目录

- - 📌 你学到了什么？

1. 初识 HTTP：一场没有记忆的对话

小明最近开发了一个旅游网站，每天有很多用户访问。但他发现了一个问题：
用户登录后，刷新一下页面就得重新登录？！😨

他百思不得其解，为什么网站不能记住用户的登录状态？

这时，他的师兄告诉他：

“这是因为 HTTP 是无状态的，每次请求都是全新的，服务器根本不知道你是谁。”

小明恍然大悟，但随之而来的新问题是——如何让服务器记住用户的身份呢？

2. Cookie：网站的“记忆” 🍪

师兄介绍了第一种解决方案：Cookie。

💡 Cookie 是存储在浏览器中的一小段数据，它可以在每次请求时自动携带到服务器，让服务器识别用户身份。

小明的实现方式：

用户登录成功后，服务器生成一个 Set-Cookie 响应头，把用户身份信息存到 Cookie 里：
```
Set-Cookie: user=12345; Expires=Wed, 21 Oct 2025 07:28:00 GMT
```
之后每次请求，浏览器都会自动带上 Cookie：
```
Cookie: user=12345
```
服务器检查 user=12345，发现是小明，返回登录后的页面。

🌟 Cookie 的优点：

服务器无须存储会话信息，完全由客户端管理。
支持不同域名的访问控制（如 www.example.com 和 api.example.com 共享 Cookie）。

⚠️ 但 Cookie 有几个明显的缺陷：

安全性低：存储在客户端，容易被篡改或盗取（可以使用 HttpOnly 限制 JS 访问）。
存储空间有限：单个 Cookie 不能超过 4KB，大量数据存不下。
每次请求都会携带，影响带宽和性能。

小明想了想，发现 Cookie 存在安全性问题，不太适合存储敏感信息，比如登录凭证。于是，他又去了解新的方案。

3. Session：服务端的“记忆” 🎯

师兄又介绍了另一种方案：Session。

💡 Session 通过在服务器端存储用户信息，并用一个唯一的 Session ID 让用户“自报家门”。

小明的实现方式：

用户登录成功后，服务器生成一个Session ID（如abc123），并存储用户信息：
```
session.setAttribute("user", "小明");
```
服务器通过 Set-Cookie 把 Session ID 发送给浏览器：
```
Set-Cookie: session_id=abc123; HttpOnly
```
之后用户的请求会带上 session_id=abc123，服务器查找对应的用户信息，返回登录页面。

🌟 Session 的优点：

更安全：用户信息存储在服务器，不会暴露在客户端。
可以存储更大的数据，不像 Cookie 受 4KB 限制。

⚠️ 但也有缺点：

占用服务器资源：每个用户都需要服务器存储 Session，会增加内存和数据库的压力。
无法跨域：不同域名下的 Session 不能共享。

小明发现，Session 解决了 Cookie 的安全问题，但如果用户量大，Session 可能会占用太多服务器资源。
于是，他又去探索更轻量级的身份认证方案。

4. JWT：让用户自己带着“身份证” 🔑

这时，小明听说了一种无状态的身份认证方式——JWT（JSON Web Token）。

💡 JWT 是一种基于 Token（令牌）的身份认证机制，用户登录后，服务器返回一个加密的 Token，之后用户只需带上这个 Token 进行身份认证，服务器不需要存储 Session。

小明的实现方式：

用户登录成功后，服务器生成一个 JWT Token：
```
{
  "userId": 12345,
  "exp": "2025-12-31T23:59:59Z"
}
```
服务器用密钥对它进行加密并返回给用户：
```
Authorization: Bearer eyJhbGciOiJIUzI1NiIsIn...
```
之后用户每次请求时，把 JWT 放入 Authorization 头里：
```
Authorization: Bearer eyJhbGciOiJIUzI1NiIsIn...
```
服务器用密钥解密 JWT，验证其有效性，然后解析出 userId=12345，继续处理请求。

🌟 JWT 的优点：

无状态，适用于分布式系统：服务器不需要存储 Session，适合微服务架构。
支持跨域访问：不像 Cookie 受 Same-Origin Policy 限制，JWT 可以放在 Authorization 头里，跨域传输。
可携带额外信息：可以嵌入用户角色、权限等信息，减少数据库查询。

⚠️ 但 JWT 也有缺点：

一旦被泄露，无法撤销（Session 可以在服务器端删除）。
Token 过大，每次请求都带上 JWT，会占用带宽。

小明发现，JWT 适合无状态的微服务架构，但如果只是在单体应用里，Session 可能更适合。

5. Cookie vs Session vs JWT 总结 📊

方案	存储位置	适用场景	安全性	服务器压力	是否支持跨域
Cookie	客户端	轻量级存储，如用户偏好	❌ 易被篡改	✅ 低	⚠️ 受 Same-Origin 限制
Session	服务器	传统 Web 应用，单体架构	✅ 安全	❌ 高（需存 Session）	❌ 不能跨域
JWT	客户端	分布式系统、微服务	⚠️ 需保护 Token	✅ 低（无状态）	✅ 支持

6. 最终选择：用对工具才是关键！ 🔥

小明终于明白了：

简单存储 👉 用 Cookie
单体应用的用户认证 👉 用 Session
微服务、移动端 API 认证 👉 用 JWT

他兴奋地优化了自己的旅游网站，并根据需求选择了合适的身份认证方式。😃

📌 你学到了什么？

✅ HTTP 是无状态的，需要额外机制记住用户身份。
✅ Cookie 存储在客户端，适用于轻量级数据存储，但不适合存敏感信息。
✅ Session 存储在服务器，更安全，但占用资源，不支持跨域。
✅ JWT 是无状态的 Token 认证方式，适用于分布式系统，但需要妥善管理 Token。

博客主页: 总是学不会.