Как работает аутентификация через API-ключ
Сервис выдаёт клиенту строку — случайную последовательность символов (обычно 32–64 байта в base64 или hex). При каждом запросе клиент передаёт ключ в HTTP-заголовке:
GET /api/recommendations?user_id=123
Authorization: Bearer sk-live-abc123def456...
или
X-API-Key: sk-live-abc123def456...
Сервер проверяет ключ, определяет, кому он принадлежит и какие права у этого клиента, и отвечает соответственно.
Уровни доступа в e-commerce интеграциях
Правильная архитектура предусматривает несколько ключей с разными правами:
| Тип ключа | Где используется | Права |
|---|---|---|
| Публичный (frontend) | JavaScript на сайте | Только чтение: получение рекомендаций, виджеты |
| Приватный (backend) | Сервер, CI/CD | Запись событий, управление конфигурацией |
| Серверный write-only | Event коллектор | Только запись событий без чтения данных |
Публичный ключ допустимо размещать в клиентском коде — но только если он строго ограничен правами «только чтение» и привязан к разрешённым доменам-источникам.
Типичные ошибки
- Приватный ключ в исходном коде репозитория → автоматические сканеры обнаружат его через минуты после публикации на GitHub
- Один ключ на все сервисы → компрометация одного ключа даёт доступ ко всему
- Ключи без ротации годами → при утечке невозможно определить, с какого момента данные скомпрометированы
- Ключи в URL-параметрах → они попадают в логи серверов, прокси и браузерную историю