Это вопрос “с подвохом” для собеседований, в котором СА может запутаться и сказать, что это про одно и то же.
Но разница принципиальная — по смыслу, по рискам, по архитектуре.
🔑 API-ключ (API-key)
API-ключ — это неизменяемый секрет, который идентифицирует приложение/клиента и даёт доступ к API по заранее заданным правилам.
Выдаётся разово и чаще всего не обновляется в течение всего времени жизни интеграции.
Ключевое:
+ обычно не имеет ограничения по сроку жизни или живёт очень долго (годами), пока его не перевыпустят/не отзовут
+ обычно привязан к проекту/приложению, а не к пользователю
+ сам по себе редко несёт “права” внутри, права чаще задаются настройками на стороне сервиса
+ отлично подходит для межсистемных интеграций, где не нужно знать о пользователе
+ используется в header и в query-параметрах
Пример использования в header:
GET /v1/orders
headers:
X-API-Key: 9f3a...a12
Пример использования в query-параметре (хуже по безопасности):
GET /v1/orders?api_key=9f3a...a12
Когда используют API-ключ:
✅ простые интеграции backend → внешний сервис
✅ технический доступ для серверов/скриптов
Пример:
Яндекс.Погода
⚠️ Минус: ключ часто живёт долго.
Утёк ключ - утекла учётка и её надо блокировать / создавать новую / перевыпускать постоянный ключ.
Это может требовать внешнтатное обновление системы - чтобы обновить ключ.
🎫 Токен (Token)
Токен — это временный пропуск (credential), который подтверждает право доступа на ограниченное время и часто с ограниченным набором прав (scopes/claims).
По сути это тоже секрет как и API-key, но он имеет ограниченный срок жизни и другие ограничения.
Если API-key выдают для системы/приложения сразу и его надо использовать в прямом виде, то в случае с токеном для приложения обычно выдают логин и пароль, которые оно должно обменивать на токен через отдельный эндпоинт:
POST /token
Каждый раз когда токен устаревает, надо заново обменивать логин и пароль на токен отдельным запросом:
POST /token
Ключевое:
+ обычно имеет ограниченный срок жизни (минуты/часы)
+ может быть выдан как для пользователя, так и для приложения
+ часто выдаётся после вызова отдельного эндпоинта для обмена логина+пароля на токен (например, в OAuth 2.0, также делают аналогичные эндпоинты и без OAuth 2.0)
+ может быть JWT (со “встроенными” правами), Bearer или просто строка.
Пример использования в запросах после авторизации (Bearer token):
GET /v1/orders
headers:
Authorization: Bearer eyJhbGciOi...
Когда используют токены:
✅ OAuth 2.0 / SSO: Войти через Google / Mail.ru / Госуслуги
✅ доступ к данным пользователя (email, профиль, диск, календарь)
✅ микросервисы/enterprise, где нужен короткоживущий доступ и строгие политики доступа
Пример:
FoodDeliveryGA с OAuth 2.0, где получение токена идёт по одному из авторизационных flow
⚠️ Даже если токен утёк, то его можно перевыпустить в штатном режиме с минимальными рисками. Так как перевыпуск токена каждый час (или другой промежуток времени) уже заложены в стандартном алгоритме работы.
👉 Итого, главные отличия
🔑 API-ключ = постоянный пропуск (пароль) для приложения
🎫 Токен = временный пропуск (пароль) для приложения / пользователя с ограничениями по правам доступа
#ИнтеграцииGA
#FoodDeliveryGA_oauth