{"schemaVersion":"drillso.agent.session.v1","scope":"node","resource":{"type":"shared-session","shareId":"B_Qh5EPwQq0l","title":"API Key 和 Bearer Token 是什么，有啥区别？","canonicalUrl":"https://drillso.com/en/share/sessions/B_Qh5EPwQq0l/api-key-4dd39ad5","agentUrl":"https://drillso.com/en/share/sessions/B_Qh5EPwQq0l/agent.json?node=api-key-4dd39ad5","ownerName":"pyth0nb3st","updatedAt":"2026-04-28T10:23:26.413Z"},"currentNode":{"id":"4dd39ad5-87ea-42f7-b800-fea1e4b2d892","slug":"api-key-4dd39ad5","title":"API Key","type":"page","url":"https://drillso.com/en/share/sessions/B_Qh5EPwQq0l/api-key-4dd39ad5","agentUrl":"https://drillso.com/en/share/sessions/B_Qh5EPwQq0l/agent.json?node=api-key-4dd39ad5","text":"## 先说结论\n\n很多 AI 平台把 **API Key 放在 `Authorization: Bearer <key>`** 后面，**主要不是因为 API Key 本质上变成了 OAuth 的 Bearer Token**，而是因为：\n\n- **HTTP 标准里已经有现成的授权头：`Authorization`**\n- `Bearer` 是最通用、最容易被各种客户端/网关/SDK 支持的方案\n- 对服务端来说，**“拿着这个 key 就能调用”** 的语义，和 Bearer 模式非常接近\n- 这样做比自定义请求头（如 `X-API-Key`）更统一、更标准化\n\n也就是说，很多平台这么设计，更多是**工程和协议层面的统一**，而不是说“API Key = JWT”或者“API Key = OAuth Access Token”。\n\n---\n\n## API Key 到底是什么？\n\n**API Key** 本质上是一串发给客户端的凭证，用来标识：\n\n- 你是谁的应用/账号\n- 你有没有权限调用某些接口\n- 调用量该记到谁头上\n- 是否需要限流、计费、审计\n\n典型例子：\n\n```http\nAuthorization: Bearer sk-xxxxxxxx\n```\n\n这里后面的 `sk-xxxxxxxx` 可能只是一个**随机字符串**，并不一定是 JWT，也不一定包含可解析的用户信息。\n\n### 它常见的特点\n\n- 往往由平台生成\n- 通常比较长，难猜\n- 可能长期有效，也可能可轮换\n- 经常和账户、项目、组织、权限范围绑定\n\n---\n\n## 为什么放到 Bearer 后面？\n\n### 1. Bearer 表达的是“使用方式”，不是“令牌格式”\n\n这是最关键的一点。\n\n`Bearer` 的意思是：\n\n> **谁带来了这个凭证，谁就被当作有权限。**\n\n而 API Key 在很多场景下也正是这么用的：\n\n- 你提交 key\n- 服务端验证 key 是否存在、有效、没被禁用\n- 如果通过，就允许访问\n\n这和 Bearer 的思想高度一致。\n\n所以：\n\n- **Bearer**：强调“持有即用”的授权方式\n- **API Key**：强调“凭证的类型/用途”\n\n两者并不冲突。\n\n---\n\n### 2. 用 `Authorization` 头更标准\n\nHTTP 已经有一个专门做认证/授权的头：\n\n```http\nAuthorization: <scheme> <credential>\n```\n\n其中：\n\n- `<scheme>` 是认证方案，比如 `Basic`、`Bearer`\n- `<credential>` 是具体凭证\n\n所以平台只要复用这个结构即可：\n\n```http\nAuthorization: Bearer <api_key>\n```\n\n好处是：\n\n- 各种 HTTP 客户端都天然支持\n- 代理、网关、WAF、日志系统更容易识别\n- SDK 写起来统一\n- 文档更简洁，用户更熟悉\n\n相比之下，如果用：\n\n```http\nX-API-Key: <api_key>\n```\n\n也能工作，但它是**平台自定义约定**，统一性稍差。\n\n---\n\n### 3. 方便和 OAuth / Access Token 体系兼容\n\n很多 AI 平台不只有 API Key，还可能同时支持：\n\n- 用户登录得到的 access token\n- 服务账号 token\n- OAuth 授权 token\n- 临时 session token\n\n如果都统一放在：\n\n```http\nAuthorization: Bearer <token>\n```\n\n那服务端和中间层处理就更一致：\n\n- 都从同一个 header 取凭证\n- 都走统一的认证中间件\n- 再根据 token 前缀、数据库记录、签名方式判断它到底是什么\n\n例如伪代码：\n\n```python\nauth = request.headers.get(\"Authorization\")\nscheme, credential = parse_auth_header(auth)\n\nif scheme != \"Bearer\":\n    reject()\n\nidentity = validate_credential(credential)  # 可能是 API Key，也可能是 OAuth token\n```\n\n这就是为什么很多现代平台喜欢“表面统一成 Bearer”。\n\n---\n\n## 这是不是严格意义上的 Bearer Token？\n\n**从广义上说，是的。**\n\n因为它符合 Bearer 的核心特征：\n\n- 持有者提交凭证即可访问\n- 服务端重点验证“凭证有效性”\n- 不额外证明“你是不是原始领取者”\n\n但**从狭义的 OAuth 2.0 语境**看，人们提到 Bearer Token 时，常常默认是：\n\n- access token\n- 短期有效\n- 可配合 refresh token\n- 带 scope\n\n而很多 API Key：\n\n- 生命周期更长\n- 更偏向“应用身份”而不是“用户会话”\n- 常用于服务对服务调用\n\n所以它们**实现形态不同**，只是**承载方式相同**。\n\n---\n\n## 为什么 AI 平台特别喜欢这样做？\n\nAI 平台通常有这些需求：\n\n- 第三方开发者接入要简单\n- CLI、后端服务、脚本都能方便调用\n- 统一计费、限流、审计\n- 尽量避免用户自己设计复杂签名逻辑\n\n如果采用 Bearer 头，调用非常直接：\n\n```bash\ncurl https://api.example.com/v1/chat \\\n  -H \"Authorization: Bearer $API_KEY\" \\\n  -H \"Content-Type: application/json\"\n```\n\n这比 HMAC 签名那类方案简单得多。  \n对开发者体验来说非常友好。\n\n---\n\n## 你可以这样理解：它像“门票”，不太像“身份证”\n\n### Bearer / API Key 模式像：\n\n- 门禁卡\n- 电影票\n- 酒店房卡\n\n系统主要判断：\n\n- 卡是真的还是假的\n- 卡有没有过期\n- 卡有没有权限开这扇门\n\n而不是判断：\n\n- 当前拿卡的人是不是最初领卡的人\n\n这就是为什么 **API Key 一旦泄露就很危险**。\n\n---\n\n## 安全上要注意什么？\n\n既然 API Key 放在 Bearer 后面，本质上就是“持有即用”，所以要特别注意：\n\n- **必须走 HTTPS**\n- **不要把 key 写进前端公开代码**\n- **不要提交到 Git 仓库**\n- **尽量用环境变量存储**\n- **定期轮换**\n- **设置最小权限**\n- **配合项目级隔离、限流、IP 白名单等措施**\n\n---\n\n## 一句话总结\n\n很多 AI 平台把 API Key 写成：\n\n```http\nAuthorization: Bearer <API_KEY>\n```\n\n本质原因是：\n\n> **它们把 API Key 当成一种“持有即用”的授权凭证，并借用 HTTP 标准的 `Authorization: Bearer` 形式来统一认证接口。**\n\n---\n\n## 你还可以继续深挖的几个相关概念\n\n- **API Key vs Access Token**\n- **Bearer Token vs JWT**\n- **OAuth 2.0**\n- **Scope / 权限范围**\n- **HMAC 签名认证**\n- **为什么前端不能直接暴露 API Key**\n- **短期 token 和长期凭证的安全差异**\n\n如果你愿意，我也可以继续给你画一个 **“API Key、Bearer Token、JWT、OAuth 之间关系图”**，让这几个概念一次彻底分清。","markdown":"## 先说结论\n\n很多 AI 平台把 **API Key 放在 `Authorization: Bearer <key>`** 后面，**主要不是因为 API Key 本质上变成了 OAuth 的 Bearer Token**，而是因为：\n\n- **HTTP 标准里已经有现成的授权头：`Authorization`**\n- `Bearer` 是最通用、最容易被各种客户端/网关/SDK 支持的方案\n- 对服务端来说，**“拿着这个 key 就能调用”** 的语义，和 Bearer 模式非常接近\n- 这样做比自定义请求头（如 `X-API-Key`）更统一、更标准化\n\n也就是说，很多平台这么设计，更多是**工程和协议层面的统一**，而不是说“API Key = JWT”或者“API Key = OAuth Access Token”。\n\n---\n\n## API Key 到底是什么？\n\n**API Key** 本质上是一串发给客户端的凭证，用来标识：\n\n- 你是谁的应用/账号\n- 你有没有权限调用某些接口\n- 调用量该记到谁头上\n- 是否需要限流、计费、审计\n\n典型例子：\n\n```http\nAuthorization: Bearer sk-xxxxxxxx\n```\n\n这里后面的 `sk-xxxxxxxx` 可能只是一个**随机字符串**，并不一定是 JWT，也不一定包含可解析的用户信息。\n\n### 它常见的特点\n\n- 往往由平台生成\n- 通常比较长，难猜\n- 可能长期有效，也可能可轮换\n- 经常和账户、项目、组织、权限范围绑定\n\n---\n\n## 为什么放到 Bearer 后面？\n\n### 1. Bearer 表达的是“使用方式”，不是“令牌格式”\n\n这是最关键的一点。\n\n`Bearer` 的意思是：\n\n> **谁带来了这个凭证，谁就被当作有权限。**\n\n而 API Key 在很多场景下也正是这么用的：\n\n- 你提交 key\n- 服务端验证 key 是否存在、有效、没被禁用\n- 如果通过，就允许访问\n\n这和 Bearer 的思想高度一致。\n\n所以：\n\n- **Bearer**：强调“持有即用”的授权方式\n- **API Key**：强调“凭证的类型/用途”\n\n两者并不冲突。\n\n---\n\n### 2. 用 `Authorization` 头更标准\n\nHTTP 已经有一个专门做认证/授权的头：\n\n```http\nAuthorization: <scheme> <credential>\n```\n\n其中：\n\n- `<scheme>` 是认证方案，比如 `Basic`、`Bearer`\n- `<credential>` 是具体凭证\n\n所以平台只要复用这个结构即可：\n\n```http\nAuthorization: Bearer <api_key>\n```\n\n好处是：\n\n- 各种 HTTP 客户端都天然支持\n- 代理、网关、WAF、日志系统更容易识别\n- SDK 写起来统一\n- 文档更简洁，用户更熟悉\n\n相比之下，如果用：\n\n```http\nX-API-Key: <api_key>\n```\n\n也能工作，但它是**平台自定义约定**，统一性稍差。\n\n---\n\n### 3. 方便和 OAuth / Access Token 体系兼容\n\n很多 AI 平台不只有 API Key，还可能同时支持：\n\n- 用户登录得到的 access token\n- 服务账号 token\n- OAuth 授权 token\n- 临时 session token\n\n如果都统一放在：\n\n```http\nAuthorization: Bearer <token>\n```\n\n那服务端和中间层处理就更一致：\n\n- 都从同一个 header 取凭证\n- 都走统一的认证中间件\n- 再根据 token 前缀、数据库记录、签名方式判断它到底是什么\n\n例如伪代码：\n\n```python\nauth = request.headers.get(\"Authorization\")\nscheme, credential = parse_auth_header(auth)\n\nif scheme != \"Bearer\":\n    reject()\n\nidentity = validate_credential(credential)  # 可能是 API Key，也可能是 OAuth token\n```\n\n这就是为什么很多现代平台喜欢“表面统一成 Bearer”。\n\n---\n\n## 这是不是严格意义上的 Bearer Token？\n\n**从广义上说，是的。**\n\n因为它符合 Bearer 的核心特征：\n\n- 持有者提交凭证即可访问\n- 服务端重点验证“凭证有效性”\n- 不额外证明“你是不是原始领取者”\n\n但**从狭义的 OAuth 2.0 语境**看，人们提到 Bearer Token 时，常常默认是：\n\n- access token\n- 短期有效\n- 可配合 refresh token\n- 带 scope\n\n而很多 API Key：\n\n- 生命周期更长\n- 更偏向“应用身份”而不是“用户会话”\n- 常用于服务对服务调用\n\n所以它们**实现形态不同**，只是**承载方式相同**。\n\n---\n\n## 为什么 AI 平台特别喜欢这样做？\n\nAI 平台通常有这些需求：\n\n- 第三方开发者接入要简单\n- CLI、后端服务、脚本都能方便调用\n- 统一计费、限流、审计\n- 尽量避免用户自己设计复杂签名逻辑\n\n如果采用 Bearer 头，调用非常直接：\n\n```bash\ncurl https://api.example.com/v1/chat \\\n  -H \"Authorization: Bearer $API_KEY\" \\\n  -H \"Content-Type: application/json\"\n```\n\n这比 HMAC 签名那类方案简单得多。  \n对开发者体验来说非常友好。\n\n---\n\n## 你可以这样理解：它像“门票”，不太像“身份证”\n\n### Bearer / API Key 模式像：\n\n- 门禁卡\n- 电影票\n- 酒店房卡\n\n系统主要判断：\n\n- 卡是真的还是假的\n- 卡有没有过期\n- 卡有没有权限开这扇门\n\n而不是判断：\n\n- 当前拿卡的人是不是最初领卡的人\n\n这就是为什么 **API Key 一旦泄露就很危险**。\n\n---\n\n## 安全上要注意什么？\n\n既然 API Key 放在 Bearer 后面，本质上就是“持有即用”，所以要特别注意：\n\n- **必须走 HTTPS**\n- **不要把 key 写进前端公开代码**\n- **不要提交到 Git 仓库**\n- **尽量用环境变量存储**\n- **定期轮换**\n- **设置最小权限**\n- **配合项目级隔离、限流、IP 白名单等措施**\n\n---\n\n## 一句话总结\n\n很多 AI 平台把 API Key 写成：\n\n```http\nAuthorization: Bearer <API_KEY>\n```\n\n本质原因是：\n\n> **它们把 API Key 当成一种“持有即用”的授权凭证，并借用 HTTP 标准的 `Authorization: Bearer` 形式来统一认证接口。**\n\n---\n\n## 你还可以继续深挖的几个相关概念\n\n- **API Key vs Access Token**\n- **Bearer Token vs JWT**\n- **OAuth 2.0**\n- **Scope / 权限范围**\n- **HMAC 签名认证**\n- **为什么前端不能直接暴露 API Key**\n- **短期 token 和长期凭证的安全差异**\n\n如果你愿意，我也可以继续给你画一个 **“API Key、Bearer Token、JWT、OAuth 之间关系图”**，让这几个概念一次彻底分清。","structured":null,"children":[]},"breadcrumbs":[{"id":"37cc254f-9d7d-4893-a45a-b72b31f0d63c","slug":"api-key-和-bearer-token-是什么，有啥区别？-37cc254f","title":"API Key 和 Bearer Token 是什么，有啥区别？","type":"page","url":"https://drillso.com/en/share/sessions/B_Qh5EPwQq0l/api-key-%E5%92%8C-bearer-token-%E6%98%AF%E4%BB%80%E4%B9%88%EF%BC%8C%E6%9C%89%E5%95%A5%E5%8C%BA%E5%88%AB%EF%BC%9F-37cc254f","agentUrl":"https://drillso.com/en/share/sessions/B_Qh5EPwQq0l/agent.json?node=api-key-%E5%92%8C-bearer-token-%E6%98%AF%E4%BB%80%E4%B9%88%EF%BC%8C%E6%9C%89%E5%95%A5%E5%8C%BA%E5%88%AB%EF%BC%9F-37cc254f"},{"id":"31f278f7-faa0-4740-8564-d3832b8c7d64","slug":"bearer-token-31f278f7","title":"Bearer Token","type":"page","url":"https://drillso.com/en/share/sessions/B_Qh5EPwQq0l/bearer-token-31f278f7","agentUrl":"https://drillso.com/en/share/sessions/B_Qh5EPwQq0l/agent.json?node=bearer-token-31f278f7"}],"parent":{"id":"31f278f7-faa0-4740-8564-d3832b8c7d64","slug":"bearer-token-31f278f7","title":"Bearer Token","type":"page","url":"https://drillso.com/en/share/sessions/B_Qh5EPwQq0l/bearer-token-31f278f7","agentUrl":"https://drillso.com/en/share/sessions/B_Qh5EPwQq0l/agent.json?node=bearer-token-31f278f7"},"children":[],"fullTree":null,"warnings":[],"truncated":false}