认证与授权#1#Token和Cookie验证方式对比

多端兼容对比

• Cookie

1. Cookie 是 HTTP 协议规范的一部分，浏览器原生支持，并提供了请求自动携带Cookie、同源策略等等功能。 (不同浏览器实现可能存在差异)
2. Cookie 受同源策略约束，跨域请求需额外配置 CORS
3. 非浏览器端(移动端 App、IoT 设备、第三方 API 调用…) Cookie的支持不完善，可能需要额外的开发代码适配

• Token

1. 按照某个规范(如JWT…)生成的标准化字符串, 可通过参数传递(如HTTP Header…)
2. 无需依赖浏览器特性，多端(浏览器、移动端 App、智能设备…) 均可通过代码手动管理 Token (多端通用性)
3. Token 通过参数传递，不受同源策略限制，可轻松实现跨域 API 调用

状态对比

• Cookie

1. Cookie 校验通常依赖服务器端的Session 存储（如内存、Redis)，当用户量激增或系统需要水平扩展时，Session 的存储、同步和失效管理会成为性能瓶颈，尤其是跨地域的分布式系统
2. 服务器端会话管理可以随时终止会话

• Token

1. 通常Token字符串包含用户身份和元数据，减少了数据库的查询，服务器无需存储会话信息，仅需验证 Token 合法性即可。这种无状态性天然支持分布式架构，更适合现代微服务和云原生环境
2. Token一旦签发无法轻易撤销

安全性对比

• Cookie

Cookie 会被浏览器自动携带，存在CSRF(跨站请求伪造)风险，需额外防御机制(如 CSRF Token、SameSite 属性)

• Token

1. Token需要逻辑显式添加，减少了CSRF风险
2. Token 通常存储在客户端(如 LocalStorage)，可能面临 XSS 攻击窃取的风险。但可通过以下方式缓解：
   • 使用 HttpOnly Cookie 存储 Token（但会失去部分多端优势）
   • 限制 Token 有效期，结合 Refresh Token 机制
   • 避免在 Token 中存储敏感信息

场景选择

1. Token适用于多端支持、无状态架构和跨域场景 (注意安全存储问题)
2. Cookie适用于传统高安全性敏感场景 (浏览器环境可靠，多端扩展性不足)
3. Token和Cookie可混合使用(传统浏览器端用 Cookie 管理会话，第三方API调用使用短期Token 授权)

   • 用户登录：浏览器提交凭证，后端验证后生成
     • 会话 Cookie：HttpOnly + Secure + SameSite=Lax，用于维持浏览器会话
     • 短期访问 Token（JWT）：通过响应 Body 或 Header 返回给前端，用于调用 API
   • API调用
     • 浏览器端：前端从 Cookie 获取会话身份，调用 API 时在请求头添加Token
     • 第三方服务：直接使用 JWT 调用 API，无需处理 Cookie
   • 后端鉴权
     • 优先从 Header 获取 Token检验
     • 如果 Token 不存在，检查 Cookie（浏览器端会话）