HTTP认证机制

概念引入

想象飞翔科技的大楼：一楼大厅谁都能进，但财务室、服务器机房必须刷卡。HTTP 认证就是这套"门禁系统"——它告诉服务器"我是谁"，服务器决定是否放行。

HTTP 认证（HTTP Authentication）是客户端向服务器证明身份的标准机制。与在 HTML 表单里输用户名密码不同，HTTP 认证把身份信息放在请求头里，浏览器会自动弹窗、自动记住、自动发送，不用写一行前端代码。

在飞翔科技，航仔（后端）给内部系统加了认证，翼王（架构师）评估各种方案的安全性，雁姐（用户运营）则关心用户体验。

核心内容

为什么需要 HTTP 认证

当服务器收到未认证的敏感请求时，返回 401 Unauthorized（未认证），并在 WWW-Authenticate 响应头里说明认证方式。客户端随后带上 Authorization 请求头重新请求。

401 Unauthorized vs 403 Forbidden：

  • 401 = "请出示证件"（没登录或登录失败）
  • 403 = "证件有效，但你不能进"（已登录但权限不足）

Basic 认证：最原始的"明文密码"

Basic 认证把 用户名:密码 用 Base64 编码后放在请求头里：

Authorization: Basic YWhhbmc6MTIzNA==
# 解码后：ahang:1234

Base64 不是加密，只是编码——任何人都能解码。如果不用 HTTPS，密码在网络上传输就像写在明信片上。

飞翔场景：凌叔早期给内部监控面板加了 Basic 认证，翼王发现后立刻要求升级——"这等于把钥匙挂在门把手上"。

Digest 认证：挑战-响应机制

Digest 认证（摘要认证，RFC 7616）引入了"挑战-响应"（Challenge-Response）机制，密码不直接传输：

关键概念：

  • realm（领域）：认证的作用域，相当于"哪道门"
  • nonce（临时数）：服务器生成的随机数，防止重放攻击
  • response：客户端用 MD5 哈希计算出的"签名"，密码本身不出现在网络中

Digest 比 Basic 安全，但仍不够现代——不支持 HTTPS 的完整保护，且哈希算法（MD5）已被认为不够强。

Bearer 认证：现代 API 的主流

Bearer 认证（Bearer Token）是目前 REST API 的事实标准。"Bearer"意为"持票人"——谁持有这张票，谁就能通过。

GET /api/v2/users HTTP/1.1
Host: api.feixiang.net
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Token 通常由 JWT（JSON Web Token）实现，包含三部分（Header.Payload.Signature）：

eyJhbGciOiJIUzI1NiJ9.  ← Header（算法信息）
eyJ1c2VyIjoi6I6W5L2VIn0.  ← Payload（用户ID、权限、过期时间）
SflKxwRJSMeKKF2QT4fwpMe...  ← Signature（签名防篡改）

飞翔场景：空少做的官网小程序调用后端 API，风速（算法）的数据分析平台对接第三方服务，都用 Bearer Token。Token 存在 localStorage，每次请求自动带上。

表单认证 vs HTTP 标准认证

对比项HTTP 标准认证表单认证（Session/Cookie）
实现方式浏览器原生弹窗自定义登录页面
用户体验简陋，无法定制可设计精美 UI
登出机制浏览器缓存难清除服务端销毁 Session 即可
适用场景内部工具、API面向用户的网站
记住密码浏览器管理自行实现"记住我"

飞翔官网用表单认证（用户登录页），内部 Prometheus 监控用 Basic（简单快捷），API 网关用 Bearer（现代标准）。

安全性对比

认证方式密码是否传输是否防重放依赖 HTTPS推荐场景
Basic❌ Base64编码❌必须内部工具、快速原型
Digest❌ 传哈希值✅ nonce建议兼容旧系统
Bearer❌ 传 Token✅ Token可过期必须现代 API、微服务
表单+Session❌ 传 Cookie✅ Session ID必须用户网站、后台系统

本篇小结

  • HTTP 认证是客户端向服务器证明身份的标准机制，核心头字段是 WWW-Authenticate（服务器要求）和 Authorization（客户端凭证）
  • 401 Unauthorized 表示未认证，403 Forbidden 表示已认证但无权限
  • Basic 认证将 用户名:密码 Base64 编码传输，简单但不安全，必须配合 HTTPS
  • Digest 认证使用挑战-响应机制，密码不直接传输，但 MD5 哈希强度已不足
  • Bearer 认证用 Token（通常是 JWT）代替密码，是现代 API 的主流方案，支持过期和撤销
  • 表单认证适合面向用户的网站，用户体验好，但需自行处理 Session 和安全性
  • 生产环境务必启用 HTTPS，否则任何认证方式都形同虚设

动手实践

温馨提示： 以下实践示例中涉及的域名（如 www.feixiang.net）、公司场景和接口均为虚构数据，仅用于演示协议原理，实际执行时可能不会产生文档中描述的效果。建议将命令中的域名替换为你自己可访问的真实地址进行练习。

实践：用 curl 测试 Basic 认证

# 方式一：-u 参数（自动编码）
curl -u "航仔:feixiang2026" http://internal.feixiang.net/metrics

# 方式二：手动构造 Authorization 头
curl -H "Authorization: Basic $(echo -n '航仔:feixiang2026' | base64)" \
     http://internal.feixiang.net/metrics

实践：用 curl 测试 Bearer 认证

# 携带 JWT Token 访问 API
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..." \
     http://api.feixiang.net/v2/users

# 带 Token 获取当前用户信息
curl -H "Authorization: Bearer $FEIXIANG_TOKEN" \
     http://api.feixiang.net/v2/me

实践：思考题

  1. 为什么 Basic 认证的 Base64 编码"等同于明文"？用命令行演示如何解码 Basic YWhhbmc6MTIzNA==。
  2. 假设鸣哥（内容运营）的 Bearer Token 泄露了，服务器如何撤销他的访问权限？JWT 的"无状态"特性在这里是优势还是劣势？
  3. 翼王要求"所有内部系统必须 HTTPS + 认证"。如果某个旧系统只支持 Basic 且无法改造，你会建议用什么方案增强安全性？

查看思考题答案