apiKey — схема идентификации или доступа конкретного API, токен на предъявителя — способ предъявления OAuth token. Защита строки нужна обоим, но протокольные свойства различаются.
Ключ API
Определение
Ключ API — выданная строка-секрет, по которой сервис узнаёт вызывающее приложение, проект или подписку. Ключ говорит, кто пришёл, но не решает, что этому вызову позволено: права на объект и действие сервис проверяет отдельно.
Также ищут: API key · ключ приложения · ключ разработчика
Зачем это знать
Ключ часто определяет интеграцию, но не решает права на каждый объект. Место передачи и журналирование нужно выбрать так, чтобы не создавать новые копии секрета.
Карта понятия
Что подтверждено
OpenAPI описывает apiKey как отдельную схему безопасности с передачей в заголовке, файле cookie или параметре запроса.
Граница применимости: Схема безопасности apiKey в OpenAPI 3.1.1.
Ключ API может идентифицировать вызывающее приложение. Личность пользователя и доступ к конкретному ресурсу требуют отдельных решений и проверок, но могут опираться на один контекст или токен, содержащий клиентскую и пользовательскую идентичность. Из разделения проверок не следует обязательность разных учётных данных.
Граница применимости: Разделение аутентификации и прикладной авторизации API. Состав предъявляемых данных зависит от протокола и принятой модели доступа.
OpenAPI допускает описание ключа в заголовке, cookie или параметре запроса. Это описание интерфейса не делает размещение в URL безопасным: рекомендации Google по ключам API предупреждают об их сохранении в журналах и советуют избегать URL.
Граница применимости: Сопоставление OpenAPI 3.1.1 и документации Google Cloud о ключах API; конкретная поддерживаемая схема зависит от сервиса.
В учебной системе ключ определяет интеграцию поставщика, но сам по себе не разрешает читать заказы другого клиента. API отдельно применяет правила организации, объекта и действия.
Граница применимости: Закрытый пример идентификации вызывающей службы и прикладной авторизации; набор конкретных ролей и правил задаётся сервисом.
Для разбора вызова сохраняют идентичность интеграции, время, конечную точку и результат, а не полный ключ API. Копия ключа в журнале создаёт ещё одно место утечки действующих учётных данных.
Граница применимости: Редакторское соединение контекста аудита NIST и рекомендаций по защите ключей API. Чувствительные данные запроса также требуют своей политики.
Не путать
Ключ предъявляют API, аудит сохраняет контекст и результат вызова. Копирование полного ключа в запись аудита создаёт повторно используемую утечку.
Что проверить
- Уточните назначение ключа API.
- Выберите поддерживаемое место передачи.
- Не считайте описание OpenAPI гарантией безопасности.
- Избегайте ключа в URL и журнале.
- Проверьте организацию, объект и действие.
- Сохраняйте контекст аудита без секрета.
- Не выдавайте доступ к чужому объекту по одному ключу.
Первоисточники
- OpenAPI Specification v3.1.1
Определяет API security schemes, включая apiKey в header/cookie/query, mutualTLS, OAuth 2.0 и OpenID Connect.
- Guidelines for API Protection for Cloud-Native Systems
Задаёт API lifecycle controls для authentication, authorization, rate limits, resource limits, logging и monitoring.
- The OAuth 2.0 Authorization Framework
Определяет роли OAuth, authorization grants, access и refresh tokens, client types и основные grant flows.
- Best practices for managing API keys
Рекомендует ограничивать keys, хранить вне code и query parameters, регулярно rotate и удалять ненужные keys.
- The OAuth 2.0 Authorization Framework: Bearer Token Usage
Определяет bearer-token presentation, защиту от disclosure, Authorization header и ошибки invalid_token/insufficient_scope.