基于会话的身份验证 VS 基于令牌的身份验证

Source: Dev.to

TL;DR

• 会话式: 服务器存储会话，简单，易受 CSRF 攻击，适合传统 Web 应用。
• 令牌式: 客户端存储令牌，无状态，可扩展，需防范 XSS，完美用于 API 和 SPA。

基于会话的认证

基于会话的认证是许多 Web 应用使用的传统方式。

用户登录时，服务器会创建一个会话并在服务器上存储用户数据。包含会话 ID 的 Cookie 会发送给浏览器。浏览器会在每次请求时自动携带该 Cookie，使服务器能够识别用户。

优势

• 易于实现和理解
• 登录、退出流程简单
• 适用于传统的服务器渲染应用

局限

• 需要服务器端会话存储
• 在分布式系统中扩展困难
• 易受 CSRF 攻击，因为浏览器会自动发送 Cookie

基于令牌的认证

基于令牌的认证在现代应用中被广泛使用。

登录成功后，服务器会颁发一个令牌（通常是 JWT）。客户端存储该令牌，并在每次请求时将其发送，通常放在 Authorization 头部。服务器在不存储会话数据的情况下验证令牌。

优势

• 无状态且高度可扩展
• 非常适合 API、移动端应用和 SPA
• 在微服务架构中运行顺畅

局限

• 存放在 localStorage 的令牌易受 XSS 攻击
• 登出和令牌撤销相对复杂

为了提升安全性，令牌也可以存放在 HttpOnly Cookie 中，这样可以防止 JavaScript 访问，从而降低 XSS 风险。但由于 Cookie 会自动发送，这种方式可能仍需 CSRF 防护。

存储与安全的权衡

安全性在很大程度上取决于认证数据的存放位置。

• 会话存放在 Cookie 中
  Cookie 会随请求自动发送，这使得应用更容易受到 CSRF 攻击。使用 HttpOnly 和 Secure 标志可以降低其他风险。

• 令牌存放在客户端
  存放在 localStorage 的令牌不会自动发送，降低了 CSRF 风险，但如果浏览器中运行了恶意脚本，令牌会暴露于 XSS 攻击。

每种方案都需要在便利性、可扩展性和安全性之间取得平衡。

结论

没有一种“一刀切”的解决方案。

• 基于会话的认证 是传统 Web 应用的可靠选择。
• 基于令牌的认证 更适合现代、可扩展、以 API 为驱动的系统。

选择合适的方式并做好相应的安全防护，才是最关键的。