什么是 Authorization 标头
Authorization 请求标头携带客户端用于向服务器证明身份的凭据。其语法看似简单——一个方案名称、一个空格，以及格式取决于方案的凭据：
Authorization: <scheme> <credentials>
其他所有内容——Basic、Bearer、Digest、API 密钥——只是 <scheme> 的不同值和 <credentials> 的不同编码。
挑战-响应流程
身份验证通常由服务器发起，而非客户端。当你请求受保护资源但未提供凭据时，服务器会返回 401 Unauthorized 和一个 WWW-Authenticate 标头，指明它期望的方案：
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Admin Area"
然后客户端使用匹配的 Authorization 标头重试。如果你不确定失败的请求是否是身份验证问题，那么 401 加上 WWW-Authenticate 这一对就是线索——参见 401 vs 403: Unauthorized vs Forbidden 了解区别。
常见方案
Basic
凭据是 base64(username:password)。简单、可重复使用、每次请求都发送，并且仅在 HTTPS 下安全，因为 Base64 是可逆的。详细信息请参阅 HTTP Basic Authentication: How It Works。
Authorization: Basic YWRtaW46c2VjcmV0MTIz
Bearer
凭据是一个不透明或签名的令牌（通常是 JWT 或 OAuth 访问令牌）。令牌可以过期并携带作用域，这使得 Bearer 成为面向用户的应用程序和 API 的现代默认选择。在 Basic Auth vs Bearer Token 中比较它们。
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
如果你的令牌是 JWT，你可以使用 JWT Parser 检查其标头和载荷。
Digest
一种挑战-响应方案，使用服务器提供的 nonce 对密码进行哈希处理，因此原始密码永远不会在网络上传输。在纯 HTTP 上比 Basic 更安全，但如今已被 TLS + Bearer 令牌所取代。
API 密钥
不是注册的 HTTP 方案，但通常以 Authorization: Bearer <key>、自定义标头如 X-API-Key 或查询参数的形式携带。适用于服务间调用；请像对待密码一样对待密钥。
应该使用哪种方案？
| 需求 | 方案 |
|---|---|
| 内部 API 或快速保护，通过 HTTPS | Basic |
| 用户登录、过期/作用域访问 | Bearer (JWT/OAuth) |
| 必须避免发送密码的遗留系统 | Digest |
| 机器对机器服务调用 | API 密钥（作为 Bearer） |
常见问题
Authorization 标头的格式是什么？
Authorization: <scheme> <credentials>。对于 Basic 是 Basic base64(user:pass)；对于 Bearer 是 Bearer <token>。
Authorization: Basic 和 Bearer 有什么区别？
Basic 发送可重复使用的 username:password 凭据，以 Base64 编码。Bearer 发送一个可以过期并携带作用域的令牌。Basic 适用于内部工具；Bearer 适用于面向用户的应用程序。
什么是 WWW-Authenticate 标头？
它是服务器的挑战，随 401 响应返回，告诉客户端在重试时应使用哪种身份验证方案（和 realm）。
使用 Basic Auth generator 生成和解码 Authorization: Basic 标头，并通过 HTTP status codes reference 查找 401 等响应码。