HTTP请求头里的Authorization和Cookie有什么不同？

在 HTTP 请求头中，Authorization 和 Cookie 都可以用来“携带身份信息”，但它们的设计目的、语义边界、安全模型和使用场景有本质区别。下面从工程视角系统对比。

---

一句话总结

• Authorization：显式身份凭证，为“认证 / 授权”而生，由客户端主动控制，常用于 API / Token 鉴权
• Cookie：浏览器状态机制，为“会话保持”而生，由浏览器自动管理，常用于 Web 登录态

---

一、设计目的不同

Authorization

• HTTP 标准定义的 认证头
• 用于告诉服务端： “我是谁 / 我有什么权限”
• 每次请求都明确携带凭证

常见格式：

Authorization: Bearer <access_token>
Authorization: Basic <base64(user:password)>

Cookie

• HTTP 状态管理机制
• 用于让浏览器在无状态的 HTTP 上维持会话
• 本质是 浏览器 → 服务器 的自动键值对传递

Cookie: sessionId=abc123; theme=dark

---

二、谁来管理它们？

对比项	Authorization	Cookie
管理者	前端代码 / 客户端	浏览器
是否自动携带	❌ 否	✅ 是
是否可控	高（可精确控制）	低（浏览器策略）
是否可跨请求自定义	✅	❌

例子

// Authorization：你必须手动加
fetch('/api/user', {
  headers: {
    Authorization: 'Bearer xxx'
  }
})

// Cookie：浏览器自动带
fetch('/api/user', { credentials: 'include' })

---

三、安全模型差异（非常关键）

Cookie 的安全特点

• 自动发送（容易被滥用）

• 受浏览器安全策略影响：

  • HttpOnly：JS 不能读
  • Secure：只走 HTTPS
  • SameSite：防 CSRF

👉 Cookie 天然容易 CSRF

Authorization 的安全特点

• 不会被浏览器自动带
• 只能被 JS 主动设置
• 天然防 CSRF

👉 Token + Authorization = 默认 CSRF 安全

---

四、典型使用场景

使用 Cookie 的场景

• 传统 Web 网站
• SSR / 同域页面
• 浏览器登录态

浏览器访问页面
↓
服务端 Set-Cookie
↓
后续请求自动携带 Cookie

使用 Authorization 的场景

• 前后端分离
• SPA / 小程序 / App
• 第三方 API
• 微服务

登录接口 → 返回 token
↓
前端存 token
↓
每次请求加 Authorization

---

五、是否可以“互相替代”？

技术上可以，工程上不推荐

用法	问题
用 Cookie 放 token	CSRF 风险、跨域复杂
用 Authorization 存 sessionId	不符合语义，浏览器能力浪费

最佳实践：

• 浏览器 Web 登录态 → Cookie
• API / 跨端 / 跨域 → Authorization

---

六、前端工程角度（结合你的背景）

作为前端工程师，通常会这样选：

✅ 推荐组合

• 登录态：Cookie（HttpOnly + SameSite）
• API 鉴权：Authorization Bearer Token

❌ 常见坑

• token 存 localStorage + Cookie 自动带 → 双重风险
• Cookie 跨域 + SameSite=None + 未 HTTPS → 直接失效

---

七、核心对比表（速查）

维度	Authorization	Cookie
初衷	认证 / 授权	状态保持
是否自动携带	❌	✅
CSRF 风险	低	高
前端控制力	强	弱
跨域	易	难
API 友好度	⭐⭐⭐⭐⭐	⭐⭐