Authorization 是什么
Authorization 是客户端向服务器证明身份的请求头，格式是「认证方案 + 凭证」。常见方案有三类：基础认证把用户名与口令编码后放进头部；令牌认证携带不透明令牌或结构化令牌；摘要认证用挑战与应答计算出摘要，避免明文口令。它是应用层认证的统一入口，也是日志与转发环节最容易出问题的地方——一旦被完整记录或转发到第三方，等于把凭证交了出去。
基本信息
| 名称 | Authorization（RFC 9110 §11.6.2） |
|---|---|
| 作用 | 向服务端证明身份 |
| 常见方案 | 基础认证、令牌认证、摘要认证，各有独立规范 |
| 配套头部 | 服务端用挑战头声明接受哪些方案 |
| 安全要求 | 必须走加密通道，禁止写入日志与前端代码 |
典型使用场景
- 接口调用：携带令牌访问受保护资源
- 服务之间调用：使用长期凭证或客户端证书识别调用方
- 命令行调试：临时携带令牌复现问题
- 网关与代理转发：把凭证透传给后端，同时避免写入访问日志
- 自动化脚本：从密钥管理系统中取出凭证注入到请求头
令牌与基础认证写法
令牌与基础认证写法
curl -si -H 'Authorization: Bearer eyJhbGciOi' https://api.example.com/me # 令牌认证
curl -si -u user:password https://api.example.com/me # 基础认证，工具会自动做编码
curl -si -H 'Authorization: Basic dXNlcjpwYXNz' https://api.example.com/me # 手工写编码后的凭证
# 先看服务端接受什么方案，可以不带凭证发一次请求
curl -si https://api.example.com/private | grep -i '^www-authenticate'三种方案怎么选
| 方案 | 凭证形态 | 适用与注意 |
|---|---|---|
| 基础认证 | 编码后的用户名口令 | 实现最简单，必须配加密通道，不适合长期凭证 |
| 令牌认证 | 不透明或结构化令牌 | 接口首选，需配套过期、刷新与吊销机制 |
| 摘要认证 | 挑战与应答计算出的摘要 | 避免明文口令，但实现复杂、生态支持少 |
| 客户端证书 | 双向握手中出示证书 | 适合服务之间调用，运维与证书轮换成本较高 |
实践要点
- 凭证只在请求头里传递，绝不放进地址参数、页面内容或前端可见配置
- 服务端日志要脱敏：保留方案前缀与长度即可，不要记录完整值
- 跨域转发时按目标裁剪头部，不要把内部凭证透传给第三方接口
- 网关做头部改写时保留原值，避免后端拿到被加工过的凭证而认证失败
- 为不同用途发放不同凭证，便于单独吊销与追踪泄漏来源
它是敏感凭证头：网关与应用的日志默认不应落完整值，抓包与转发也要谨慎。基础认证只是编码而不是加密，明文连接上发送等同于公开口令；令牌放进地址参数则会进入日志与来源头，风险比放在请求头高得多。
服务端声明的认证方案决定了客户端该带什么凭证。客户端收到未认证响应后应先看挑战头，而不是盲目重试；自动化脚本里常见的问题就是忽略了方案声明，反复发送服务端并不接受的凭证形式。
常见故障对照
| 现象 | 可能原因 |
|---|---|
| 请求头被服务端当成不存在 | 方案前缀拼写错误或缺少空格分隔 |
| 后端始终认证失败 | 网关改写了头部或重复添加了凭证 |
| 凭证在日志里被完整打印 | 访问日志格式包含该头且未做脱敏 |
| 跨域请求带不上凭证 | 客户端与响应的跨域策略未同时允许携带凭证 |