Аутентификация LLM API у разных провайдеров: API keys, OAuth, service accounts и gateway passthrough

Практический справочник по аутентификации в OpenAI, Anthropic, DashScope, DeepSeek, SiliconFlow и Google Gemini: форматы заголовков, OAuth/service-account варианты, паттерны gateway passthrough и типовые причины 401/403.

2026-08-02· TheRouter

Аутентификация LLM API кажется простой, пока вы не подключаете несколько провайдеров одновременно. Один использует Authorization: Bearer ..., другой — x-api-key, Google Gemini может работать с API key, а Google Cloud/Vertex AI обычно требует OAuth, ADC или service account. Административные API часто используют отдельный класс credential, отличный от inference API.

Это практический reference по механике auth и форме запроса. Управление секретами, rotation и governance вынесены в отдельный материал: LLM API key management guide.

OpenAI-совместимость означает, что провайдер предоставляет endpoint chat-completions, чей контракт запроса и ответа достаточно близок к API OpenAI, чтобы немодифицированный вызов OpenAI SDK работал после замены трёх значений: API key, base URL, название модели. Минимальная поверхность на практике —POST /v1/chat/completions с messages, model и потоковым ответом в форме OpenAI.

Сравнение за 30 секунд

Провайдер	Основной auth для inference	Header / форма	Контекст аккаунта	OAuth / service account	Production gotcha
OpenAI	API key или short-lived access token	`Authorization: Bearer <token>`	Иногда нужны organization/project headers	Workload Identity Federation для short-lived токенов	Legacy user keys и project keys могут вести к разному billing/context.
Anthropic	API key	`x-api-key: <key>` + `anthropic-version`	Admin API использует admin keys	OAuth не является обычным публичным inference path	401/403 часто означает malformed/revoked key или неправильный workspace/org доступ.
DashScope / Alibaba Model Studio	Model Studio API key	В OpenAI-compatible SDK задаётся `api_key`; raw HTTP часто bearer-style	Endpoint может включать `{WorkspaceId}`	RAM/account controls вокруг создания key и workspace	Key зависит от region/workspace; base URL важен так же, как сам key.
DeepSeek	API key	`Authorization: Bearer ${DEEPSEEK_API_KEY}`	Разные OpenAI- и Anthropic-format base URLs	Не основной public inference path	Нельзя поменять только `base_url` и оставить старый provider key.
SiliconFlow	API key	OpenAPI объявляет `bearerAuth`	Base URL `https://api.siliconflow.com/v1` или regional variant	Не основной public inference path	Auth success не означает доступность каждого model ID.
Google Gemini	Gemini API key; Google Cloud через OAuth/service account	API key или OAuth bearer	Project/quota context важен	OAuth 2.0, ADC и service accounts — стандарт Google Cloud	Сначала определите surface: AI Studio/Gemini API или Vertex AI/Google Cloud.

Почему auth у LLM API отличается

Форма auth отражает границы продукта. Developer-first API начинают с долгоживущих API keys — это просто для SDK. Enterprise cloud добавляет project, workspace, IAM/RAM, billing и audit. Admin API может управлять users, keys и audit logs, поэтому обычно требует отдельный credential class. OpenAI-compatible протокол нормализует body, но не нормализует identity.

Именно здесь чаще всего ошибаются: SDK может скрыть различия в клиентском коде, но Anthropic key не станет валидным для DeepSeek, а gateway не угадает, какой Alibaba Workspace должен платить за запрос.

По провайдерам

OpenAI

OpenAI API принимает bearer credentials: обычные API keys или short-lived access tokens из workload identity federation.

Authorization: Bearer OPENAI_API_KEY_OR_ACCESS_TOKEN

OpenAI также разделяет обычные API keys и Admin API keys для workflows уровня организации: users, projects, API keys, audit logs. Для приложений используйте project-scoped keys; admin keys держите только в отдельной automation с минимальным доступом.

Anthropic

Нативный Claude API обычно использует x-api-key и anthropic-version. Документация Anthropic также отделяет Admin API credentials от обычных inference keys. Не кладите admin credential в inference proxy только потому, что оба секрета называются Anthropic keys.

Разделяйте inference keys, admin keys и CI keys по разным secret paths и access policies.

DashScope / Alibaba Model Studio

Model Studio требует создать API key перед вызовом моделей. OpenAI-compatible документация говорит, что при миграции нужно поменять API key, BASE_URL и model name; также указаны region/workspace-specific domains.

Поэтому DashScope credential — это не только token. Endpoint может кодировать region и workspace, а key может иметь all-model или custom permissions, включая IP whitelist и model scope. Храните key, base URL, region и workspace как единый credential profile.

DeepSeek

DeepSeek документирует OpenAI-compatible base URL https://api.deepseek.com и HTTP пример:

Authorization: Bearer ${DEEPSEEK_API_KEY}

Есть и Anthropic-format base URL. Протокол совместим, но credential остаётся DeepSeek-specific.

SiliconFlow

В SiliconFlow OpenAPI для chat completions указан bearerAuth, server URL — https://api.siliconflow.com/v1. Для OpenAI SDK обычно достаточно заменить SiliconFlow API key и base URL, сохранив привычный request body.

Так как SiliconFlow агрегирует множество model families, отделяйте auth success от model availability. Успешный health check на одном cheap model не доказывает, что весь routing table доступен этому аккаунту.

Google Gemini и Google Cloud

У Google несколько правильных auth paths. Gemini API / AI Studio quickstarts часто используют API key. Google Cloud services, включая Vertex AI, используют OAuth 2.0, Application Default Credentials и service accounts.

Практическое правило: лёгкий Gemini API integration — API key path; enterprise Google Cloud workload — service account или Workload Identity через ADC; не называйте оба секрета одинаково GOOGLE_API_KEY.

Gateway passthrough и credential normalization

OpenAI-compatible gateway вроде TheRouter может стандартизировать client-facing API: приложение отправляет OpenAI-style request на один base URL, а routing policy выбирает provider/model. Но это не означает, что gateway стирает provider auth semantics.

Держите четыре слоя отдельно:

client-to-gateway authentication;
gateway policy identity — project, team, budget, route table;
provider credential profile — key, base URL, region, workspace, optional headers;
provider response metadata — request IDs, rate-limit headers, auth errors, billing/account signals.

TheRouter поддерживает OpenAI-compatible routing patterns там, где настроены provider paths. Не обещайте universal model support, zero downtime или guaranteed cheapest routing. Честная ценность — controlled normalization.

Что выбрать: API key, OAuth, service account или proxy credential?

Browser/mobile client? Никогда не кладите provider key в клиент. Используйте backend или gateway.
Server-to-developer API? Используйте provider API keys или short-lived tokens, если они поддерживаются.
Google Cloud / enterprise cloud workload? Предпочитайте service accounts, Workload Identity или ADC.
Admin automation? Отдельные admin-scoped credentials в изолированном job/service account.
Multi-provider routing? Создайте named credential profile для каждого provider+region+workspace.

Типовые причины 401/403

Симптом	Вероятная причина	Проверка
Все запросы сразу 401	Credential отсутствует, malformed, expired или revoked	Печатайте только prefix/length; проверьте env var; rotate if exposed.
403 после успешного auth	Нет доступа к model, project, workspace или region	Проверьте membership и model enablement.
Локально работает, CI падает	Secret не смонтирован или другое имя переменной	Сравните env vars и CI secret scope.
Один model работает, другой нет	Model не разрешён или недоступен	Тестируйте known-enabled model и смотрите provider error body.
OpenAI SDK unauthorized после смены `base_url`	Остался старый provider key	Храните `base_url`, key и model в одном config object.
Google выдаёт quota/project error	Перепутаны API key path и Google Cloud identity	Уточните: Gemini API key или OAuth/ADC.

Credential profile pattern

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;
};

Не держите этот объект в application code. Приложение запрашивает model; routing config решает, какой provider credential profile прикрепить.

Production checklist

Inventory credentials by provider, environment, project, workspace, region, owner and rotation policy.
Separate inference credentials from admin credentials.
Store base URL, region/workspace and auth type together with the key.
Add low-cost health checks per provider profile and critical model family.
Log provider request IDs and sanitized auth failure categories.
Never log full keys, OAuth tokens, service-account JSON or signed headers.
Link auth errors to the error-handling reference.
Browser/mobile traffic should call your backend or gateway, never providers directly.

FAQ

Is `Authorization: Bearer` universal for LLM APIs?

No. It is common for OpenAI-compatible providers, but Anthropic native API uses x-api-key, and Google depends on product surface.

Can a gateway hide all auth differences?

Not completely. It can hide client-code differences, but still needs provider-specific credential profiles internally.

Should one provider key be shared by all services?

No. Separate keys by environment, workload and blast-radius boundary.