Cookie Session Token
·
giftia
| 特性 | Cookie | Session | Token |
|---|---|---|---|
| 本质 | 客户端存储技术 | 服务端状态管理机制 | 授权凭证、身份令牌 |
| 数据内容 | 少量文本数据（如 Session ID、用户偏好等） | 服务器存储的完整用户数据（如登录状态、购物车） | 用户的身份信息和权限，通常是自包含的 |
| 存储位置 | 客户端浏览器 | 服务端内存或数据库 | 客户端（通常是浏览器存储，如 LocalStorage、Cookie） |
| 认证模式 | 辅助认证，存储 Session ID | 有状态认证，服务器需要存储并查询会话 | 无状态认证，服务器不存储会话信息 |
| 工作原理 | 服务器发送 Set-Cookie 头，浏览器自动携带 Cookie 头 | 浏览器通过 Cookie 携带 Session ID，服务器根据 ID 查找会话 | 服务器生成 Token，客户端每次请求时在 Authorization 头中携带 |
| 安全性 | 较低。易被窃取和篡改。 | 较高。敏感数据在服务端，但依赖 Cookie 易受 CSRF 攻击。 | 较高。使用签名防止篡改，但 Token 一旦泄露，难以吊销。 |
| 存储大小 | 极小，通常 4KB | 较大，取决于服务器资源 | 可大可小，取决于存储的数据，通常为几十到几百字节 |
| 使用场景 | 网站个性化、跟踪用户行为、存储不敏感数据 | 传统 Web 应用的登录、购物车等需要存储大量会话数据的场景 | API 认证、移动应用、前后端分离应用、微服务架构 |
三者之间的关系总结
Cookie 和 Session 的关系：
- Cookie 是一种工具，Session 是一种机制。
- 传统的 Session 认证机制依赖于 Cookie。服务器生成 Session，然后把唯一的 Session ID 放在 Cookie 中发给浏览器。浏览器在后续请求中携带这个 Cookie，服务器才能识别用户。
Session 和 Token 的关系：
- 两者都是用来识别用户身份的。
- Session 认证是“有状态”的：服务器必须保存会话信息。
- Token 认证是“无状态”的：服务器不需要保存任何会话信息，只需要验证 Token 的有效性。
Token 和 Cookie 的关系：
- 两者是不同的概念，但可以相互结合。
- Token 本身只是一个字符串。客户端可以把它存储在 Cookie 中，也可以存储在 LocalStorage 中。
- 将 Token 存储在 Cookie 中，可以利用浏览器的自动携带机制，但容易遭受 CSRF 攻击。
- 将 Token 存储在 LocalStorage 中，需要手动在请求头中添加，但可以更好地控制发送时机，避免 CSRF 风险，是前后端分离的常见做法。