TheRouter.aiTheRouter.ai
← 全部文章

LLM API 鉴权方式横评：API Key、OAuth、服务账号与网关透传

一份面向生产接入的 LLM API 鉴权参考：对比 OpenAI、Anthropic、DashScope、DeepSeek、SiliconFlow 与 Google Gemini 的 Header 形式、OAuth/服务账号路径、网关透传模式，以及常见 401/403 排障。

· TheRouter

LLM API 鉴权看起来只是“放一个 Key”，但一旦接入多个供应商，细节会迅速变多：有的使用 Authorization: Bearer ...，有的使用 x-api-key，Google Gemini 可以走 API Key，而 Google Cloud/Vertex AI 场景又常见 OAuth、ADC 和服务账号。管理端 API 还可能需要和推理接口完全不同的凭证。

这篇是生产接入参考，重点放在鉴权机制与请求形态，不重复展开密钥生命周期治理。如果你需要轮换、密钥库、泄露响应和权限边界，请搭配阅读 LLM API Key 管理指南。

OpenAI 兼容指供应商提供一个 chat-completions 接口，其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值（API key、base URL、模型名），原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model， 并返回 OpenAI 形式的流式响应。

30 秒速览

供应商推理接口主要鉴权Header 形态账号上下文OAuth / 服务账号路径生产注意点
OpenAIAPI Key 或短期访问令牌Authorization: Bearer <token>部分账号需要组织/项目上下文Workload Identity Federation 可生成短期访问令牌旧用户 Key 与项目 Key 的计费/权限上下文可能不同。
AnthropicAPI Keyx-api-key: <key> + anthropic-versionAdmin API 使用管理端 KeyOAuth 不是公开推理接口的常规路径401/403 多见于 Key 错误、撤销、过期或工作区权限不符。
DashScope / 阿里云百炼Model Studio API KeyOpenAI 兼容 SDK 配置 api_key；HTTP 调用通常是 Bearer 风格端点中可能包含 {WorkspaceId}RAM/账号权限围绕 Key 创建与工作区访问Key、地域、Workspace、Base URL 要一起管理。
DeepSeekAPI KeyAuthorization: Bearer ${DEEPSEEK_API_KEY}OpenAI 与 Anthropic 兼容端点不同不是主要公开推理路径只改 base_url 不改 Key 仍会鉴权失败。
SiliconFlowAPI KeyOpenAPI 声明 bearerAuthhttps://api.siliconflow.com/v1 或区域端点不是主要公开推理路径鉴权成功不等于所有模型都可用。
Google GeminiGemini API Key；Google Cloud 走 OAuth/服务账号API Key 或 OAuth Bearer项目与配额上下文很重要OAuth 2.0、ADC、服务账号是 Google Cloud 标准路径先判断是 AI Studio/Gemini API 还是 Vertex AI/Google Cloud。

为什么各家鉴权不一样

差异来自商业与安全边界：开发者 API 倾向 API Key，因为最容易接入；云平台需要项目、工作区、IAM/RAM、账单和审计边界；管理端 API 能操作用户、审计日志和 Key，所以通常需要更高权限凭证。OpenAI 兼容协议能统一请求体，但无法统一账号身份。

换句话说：网关或 SDK 可以减少代码分支，但不能让 Anthropic Key 在 DeepSeek 上生效，也不能自动推断阿里云哪个 Workspace 该承担账单。

各供应商鉴权要点

OpenAI

OpenAI API 使用 Bearer 凭证：标准 API Key，或通过 Workload Identity Federation 获得的短期访问令牌。

Authorization: Bearer OPENAI_API_KEY_OR_ACCESS_TOKEN

OpenAI 还区分普通 API Key 与 Admin API Key。项目级应用应优先使用项目 Key；只有确实需要管理用户、项目、Key 或审计日志的自动化任务才应持有 Admin API Key。

Anthropic

Claude 原生 API 常见形式是 x-api-key，并带 anthropic-version。Anthropic 文档也把 Admin API Key 与普通推理 Key 区分开。不要因为它们都叫 Anthropic Key，就把管理端凭证放进推理代理服务里。

建议把推理 Key、管理 Key、CI Key 分别放在不同 Secret 路径中，并设置不同的访问策略。

DashScope / 阿里云百炼

百炼要求先创建 Model Studio API Key。OpenAI 兼容文档明确指出，迁移时需要修改 API Key、BASE_URL 和模型名，并列出了按地域/Workspace 区分的专属域名。

因此百炼接入不只是一个 Token：端点可能编码地域和 Workspace，Key 也可能配置“全部模型”或自定义权限（例如 IP 白名单、可访问模型范围）。生产环境应把 Key、Base URL、地域和 Workspace 作为一个凭证档案管理。

DeepSeek

DeepSeek 文档给出 OpenAI 兼容 Base URL https://api.deepseek.com，并在 HTTP 示例中使用：

Authorization: Bearer ${DEEPSEEK_API_KEY}

DeepSeek 还提供 Anthropic 兼容 Base URL。协议可以兼容，但凭证仍属于 DeepSeek；只替换 URL 而沿用其他供应商 Key 会失败。

SiliconFlow

SiliconFlow 的 Chat Completions OpenAPI 声明 bearerAuth，服务端点为 https://api.siliconflow.com/v1。接入 OpenAI SDK 时，通常保留 Chat Completions 请求体，只替换 SiliconFlow 的 API Key 与 Base URL。

SiliconFlow 聚合了许多模型，因此要区分“鉴权成功”和“某个模型可用”。低成本健康检查模型能通过，并不代表路由表里的所有模型都已开通。

Google Gemini 与 Google Cloud

Google 最容易混淆，因为它有多条正确路径。Gemini API/AI Studio 快速接入常见 API Key；Google Cloud 服务（例如 Vertex AI 路径）则使用 OAuth 2.0、Application Default Credentials 和服务账号。

实践上可以这样分：轻量 Gemini API 用该 API 文档里的 API Key；企业 Google Cloud 工作负载用服务账号或 Workload Identity；不要把两类凭证都叫 GOOGLE_API_KEY。

网关透传与凭证归一化

像 TheRouter 这样的 OpenAI 兼容网关，可以统一客户端到网关的调用形态：应用发 OpenAI 风格请求到一个 Base URL，路由策略选择背后的供应商/模型。这里要保持克制：网关能减少客户端分支，但不应抹平供应商凭证语义。

建议把四层分开：

  1. 客户端到网关的鉴权；
  2. 网关策略身份（项目、团队、预算、路由表）；
  3. 供应商凭证档案（Key、Base URL、地域、Workspace、附加 Header）；
  4. 供应商响应元数据（Request ID、限流 Header、鉴权错误、账单/账号信号）。

TheRouter 支持在已配置供应商路径上的 OpenAI 兼容路由模式。不要把它描述成支持所有模型、零停机或保证最低价；真实价值是可控归一化。

选择 API Key、OAuth、服务账号还是代理凭证？

  1. 浏览器/移动端？ 不要暴露供应商 Key。让客户端登录你的后端或网关，由服务端调用供应商。
  2. 普通服务器调用开发者 API？ 使用供应商 API Key，若支持短期令牌则优先考虑短期令牌。
  3. Google Cloud / 企业云工作负载？ 使用服务账号、Workload Identity 或 ADC。
  4. 管理端自动化？ 单独使用管理端凭证，并放在隔离 Job 或服务账号里。
  5. 多供应商路由？ 每个供应商+地域+Workspace 建一个命名凭证档案，而不是在代码里散落原始 Key。

常见 401/403 排障

现象可能原因检查项
所有请求立刻 401凭证缺失、格式错误、过期或已撤销只打印 Key 前缀/长度；核对环境变量；必要时轮换。
鉴权后 403Key 缺少模型、项目、Workspace 或地域权限检查项目/工作区成员关系和模型开通状态。
本地正常，CI 失败Secret 未挂载或变量名不同对比环境变量名与 CI Secret Scope。
一个模型正常，另一个失败模型未授权或不可用用已知可用模型做健康检查，并查看供应商错误体。
改了 base_url 后 OpenAI SDK 未授权仍在使用旧供应商 Key把 base_url、Key、模型放进同一个配置对象。
Google 返回配额/项目错误API Key 路径和 Google Cloud 项目身份混用确认该接口需要 Gemini API Key 还是 OAuth/ADC。

凭证档案代码形态

type ProviderCredentialProfile = {
  id: string;
  provider: "openai" | "anthropic" | "dashscope" | "deepseek" | "siliconflow" | "google";
  baseUrl: string;
  auth: {
    type: "bearer" | "x-api-key" | "google-api-key" | "oauth" | "service-account";
    secretRef: string;
  };
  headers?: Record<string, string>;
  workspace?: string;
  project?: string;
  region?: string;
};

应用代码不应直接持有这个对象。应用只请求模型，路由配置决定附加哪个供应商凭证档案。

生产检查清单

  • 按供应商、环境、项目、Workspace、地域、Owner 和轮换策略盘点所有凭证。
  • 推理凭证与管理端凭证分离。
  • Key 与 Base URL、地域、Workspace、鉴权类型一起存储。
  • 每个关键供应商档案和关键模型族都有低成本健康检查。
  • 记录供应商 Request ID 和脱敏后的鉴权错误类别。
  • 不记录完整 Key、OAuth Token、服务账号 JSON 或签名 Header。
  • 把鉴权错误关联到 错误处理参考。
  • 浏览器和移动端只调用你的后端或网关。

FAQ

Authorization: Bearer 是 LLM API 通用标准吗？

不是。OpenAI、DeepSeek、SiliconFlow 等 OpenAI 兼容供应商常见 Bearer；Anthropic 原生 API 使用 x-api-key；Google 取决于产品表面，可能是 API Key，也可能是 OAuth。

网关能隐藏所有鉴权差异吗？

不能完全隐藏。它可以隐藏客户端代码差异，但背后仍然要管理供应商专属凭证档案。把归一化当成运维控制，而不是魔法兼容。

一个供应商 Key 能不能所有服务共用？

不建议。按环境、工作负载和风险边界拆分 Key，轮换和事故响应会简单很多。

来源

客服支持