Cookie 和 Token 是两种常见的身份验证机制，它们在实现方式、安全性和适用场景上有显著区别。以下是两者的对比分析：

存储位置与传输方式

存储：由服务器通过 Set-Cookie 响应头设置，自动保存在浏览器中。
传输：浏览器在每次请求时自动附加 Cookie 到请求头（Cookie: key=value）。
管理：浏览器负责存储和发送，开发者无需手动处理。

Token

存储：由服务器生成（如 JWT），需客户端手动存储（如 localStorage、内存）。
传输：需开发者显式添加到请求头（如 Authorization: Bearer ）。
管理：开发者需自行实现 Token 的存储、过期处理等逻辑。

安全性

风险：默认可能受 CSRF（跨站请求伪造）攻击（攻击者可诱骗用户发送携带 Cookie 的请求）。
防护：

  • 使用 HttpOnly 标志防止 XSS 窃取。
  • 使用 SameSite 限制跨站发送。
  • 结合 CSRF Token 增强安全。

Token

风险：若存在 localStorage 中，可能被 XSS 攻击窃取。
防护：

  • 避免存储敏感数据在 Token 中。
  • 使用 HTTPS 加密传输。
  • 设置较短的 Token 有效期。

跨域支持

Cookie受 同源策略 限制，跨域需配置 CORS 和 withCredentials。域名、协议、端口需严格一致。

Token天然支持跨域，只需在请求头中添加 Token，适合前后端分离或跨域 API 调用。

会话管理

  • 有状态：服务端维护用户登录状态。
  • 通常结合 Session 使用，服务器需保存会话状态（如内存、数据库）；

Token

  • 无状态：Token 自身包含用户信息（如 JWT 的 Payload），服务端通过验证签名确认有效性，无需存储会话。适合分布式系统或微服务架构。

有效期管理

Cookie通过 Expires 或 Max-Age 设置过期时间，支持会话级（浏览器关闭失效）或持久化。

Token过期时间由 Token 自身字段（如 JWT 的 exp）决定，服务端无法主动废止，需借助黑名单或短期有效期策略。

适用场景

传统 Web 应用（如服务端渲染）。
需浏览器自动管理身份信息的场景。

Token

前后端分离应用（如 SPA、移动端 App）。
跨域 API 调用、第三方授权（OAuth）。
无状态服务或分布式系统。

总结

特性 Cookie Token（如 JWT）
存储位置 浏览器自动管理 客户端手动存储（如 localStorage）
传输方式 自动附加到请求头（Cookie 头） 手动添加到请求头（如 Authorization 头）
安全性风险 CSRF 攻击（需防御） XSS 攻击（需防御）
安全防护 HttpOnly、SameSite、CSRF Token 短有效期、HTTPS、避免敏感数据存储
跨域支持 需配置 CORS + withCredentials 天然支持跨域
会话管理 有状态（服务端维护 Session） 无状态（Token 自包含用户信息）
服务端存储压力 需存储 Session（内存/数据库） 无状态，无需存储
有效期管理 通过 Expires/Max-Age 控制 通过 Token 内字段（如 exp）控制
主动废止会话 直接删除服务端 Session 需黑名单或等待 Token 过期
适用场景 传统 Web 应用、服务端渲染 前后端分离、API 跨域、移动端
代码控制灵活性 低（依赖浏览器行为） 高（开发者完全控制）