API Key

先说结论

很多 AI 平台把 API Key 放在 Authorization: Bearer <key> 后面，主要不是因为 API Key 本质上变成了 OAuth 的 Bearer Token，而是因为：

• HTTP 标准里已经有现成的授权头：Authorization
• Bearer 是最通用、最容易被各种客户端/网关/SDK 支持的方案
• 对服务端来说，“拿着这个 key 就能调用” 的语义，和 Bearer 模式非常接近
• 这样做比自定义请求头（如 X-API-Key）更统一、更标准化

也就是说，很多平台这么设计，更多是工程和协议层面的统一，而不是说“API Key = JWT”或者“API Key = OAuth Access Token”。

API Key 到底是什么？

API Key 本质上是一串发给客户端的凭证，用来标识：

• 你是谁的应用/账号
• 你有没有权限调用某些接口
• 调用量该记到谁头上
• 是否需要限流、计费、审计

典型例子：

Authorization: Bearer sk-xxxxxxxx

这里后面的 sk-xxxxxxxx 可能只是一个随机字符串，并不一定是 JWT，也不一定包含可解析的用户信息。

它常见的特点

• 往往由平台生成
• 通常比较长，难猜
• 可能长期有效，也可能可轮换
• 经常和账户、项目、组织、权限范围绑定

为什么放到 Bearer 后面？

1. Bearer 表达的是“使用方式”，不是“令牌格式”

这是最关键的一点。

Bearer 的意思是：

谁带来了这个凭证，谁就被当作有权限。

而 API Key 在很多场景下也正是这么用的：

• 你提交 key
• 服务端验证 key 是否存在、有效、没被禁用
• 如果通过，就允许访问

这和 Bearer 的思想高度一致。

所以：

• Bearer：强调“持有即用”的授权方式
• API Key：强调“凭证的类型/用途”

两者并不冲突。

2. 用 Authorization 头更标准

HTTP 已经有一个专门做认证/授权的头：

Authorization: <scheme> <credential>

其中：

• <scheme> 是认证方案，比如 Basic、Bearer
• <credential> 是具体凭证

所以平台只要复用这个结构即可：

Authorization: Bearer <api_key>

好处是：

• 各种 HTTP 客户端都天然支持
• 代理、网关、WAF、日志系统更容易识别
• SDK 写起来统一
• 文档更简洁，用户更熟悉

相比之下，如果用：

X-API-Key: <api_key>

也能工作，但它是平台自定义约定，统一性稍差。

3. 方便和 OAuth / Access Token 体系兼容

很多 AI 平台不只有 API Key，还可能同时支持：

• 用户登录得到的 access token
• 服务账号 token
• OAuth 授权 token
• 临时 session token

如果都统一放在：

Authorization: Bearer <token>

那服务端和中间层处理就更一致：

• 都从同一个 header 取凭证
• 都走统一的认证中间件
• 再根据 token 前缀、数据库记录、签名方式判断它到底是什么

例如伪代码：

auth = request.headers.get("Authorization")scheme, credential = parse_auth_header(auth)
if scheme != "Bearer":    reject()
identity = validate_credential(credential)  # 可能是 API Key，也可能是 OAuth token

这就是为什么很多现代平台喜欢“表面统一成 Bearer”。

这是不是严格意义上的 Bearer Token？

从广义上说，是的。

因为它符合 Bearer 的核心特征：

• 持有者提交凭证即可访问
• 服务端重点验证“凭证有效性”
• 不额外证明“你是不是原始领取者”

但从狭义的 OAuth 2.0 语境看，人们提到 Bearer Token 时，常常默认是：

• access token
• 短期有效
• 可配合 refresh token
• 带 scope

而很多 API Key：

• 生命周期更长
• 更偏向“应用身份”而不是“用户会话”
• 常用于服务对服务调用

所以它们实现形态不同，只是承载方式相同。

为什么 AI 平台特别喜欢这样做？

AI 平台通常有这些需求：

• 第三方开发者接入要简单
• CLI、后端服务、脚本都能方便调用
• 统一计费、限流、审计
• 尽量避免用户自己设计复杂签名逻辑

如果采用 Bearer 头，调用非常直接：

curl https://api.example.com/v1/chat \  -H "Authorization: Bearer $API_KEY" \  -H "Content-Type: application/json"

这比 HMAC 签名那类方案简单得多。
对开发者体验来说非常友好。

你可以这样理解：它像“门票”，不太像“身份证”

Bearer / API Key 模式像：

• 门禁卡
• 电影票
• 酒店房卡

系统主要判断：

• 卡是真的还是假的
• 卡有没有过期
• 卡有没有权限开这扇门

而不是判断：

• 当前拿卡的人是不是最初领卡的人

这就是为什么 API Key 一旦泄露就很危险。

安全上要注意什么？

既然 API Key 放在 Bearer 后面，本质上就是“持有即用”，所以要特别注意：

• 必须走 HTTPS
• 不要把 key 写进前端公开代码
• 不要提交到 Git 仓库
• 尽量用环境变量存储
• 定期轮换
• 设置最小权限
• 配合项目级隔离、限流、IP 白名单等措施

一句话总结

很多 AI 平台把 API Key 写成：

Authorization: Bearer <API_KEY>

本质原因是：

它们把 API Key 当成一种“持有即用”的授权凭证，并借用 HTTP 标准的 Authorization: Bearer 形式来统一认证接口。

你还可以继续深挖的几个相关概念

• API Key vs Access Token
• Bearer Token vs JWT
• OAuth 2.0
• Scope / 权限范围
• HMAC 签名认证
• 为什么前端不能直接暴露 API Key
• 短期 token 和长期凭证的安全差异

如果你愿意，我也可以继续给你画一个 “API Key、Bearer Token、JWT、OAuth 之间关系图”，让这几个概念一次彻底分清。