API key — самый простой способ

API key — самый простой способ авторизации: вы получаете при регистрации длинную строку, и в каждом запросе её прикладываете. Сервер по строке понимает, что вы — именно ваш аккаунт.

Никаких логинов, паролей, токенов с истечением. Ключ один, живёт долго (до явного отзыва или ротации), везде один и тот же.

Как выглядит

Обычно ключ — длинная случайная строка букв и цифр, иногда с префиксом, обозначающим тип:

sk_live_4eC39HqLyjWDarjtT1zdp7dc        ← Stripe (live secret key)
ghp_abcDEFghijKLMNopQRSTuv0123456789    ← GitHub personal access token
AIzaSyAbcDeF1234567890_xyzABC           ← Google Maps API key

Префиксы — не обязаловка, но удобно: по первым символам видно, какой это сервис и какой тип ключа (production/test, full/scoped).

Как передаётся

Конкретный способ описан в документации каждого API. Самые частые варианты:

1. В заголовке Authorization:

const response = await fetch('https://api.example.com/v1/data', {
  headers: {
    'Authorization': 'Bearer sk_live_4eC39...',
  },
});

Иногда без слова «Bearer» — просто значение. Иногда с другой схемой, например Authorization: Token sk_live_....

2. В кастомном заголовке:

const response = await fetch('https://api.example.com/v1/data', {
  headers: {
    'X-API-Key': 'sk_live_4eC39...',
  },
});

3. В query-параметре (антипаттерн, но встречается у старых API):

const url = `https://api.example.com/v1/data?api_key=sk_live_...`;
const response = await fetch(url);

Способ через query опасен тем, что URL попадает в логи, в историю браузера, в заголовок Referer. Ключ постоянный — утечёт раз, утёк навсегда. Если выбора нет — пользуйтесь, но помните о риске.

Где такое работает хорошо

API key подходит, когда:

• Доступ нужен серверу-к-серверу (бэкенд вашего сайта зовёт стороннее API). Ключ лежит в переменных окружения бэка, в браузер никогда не попадает.
• API дешёвый, лимиты разумные, риск утечки приемлем (тренировочные сервисы, тестовые ключи).
• Действия идемпотентны и нечувствительны (получить погоду, получить статистику).

Где API key — плохая идея

Ключ нельзя зашивать в JS-код, который грузится в браузер. Любой пользователь откроет DevTools, скопирует ключ из сетевых запросов или прямо из исходников — и пойдёт расходовать ваш бюджет.

Если фронту нужно общаться со сторонним API, для которого нужен секретный ключ — ставите свой бэкенд-прокси: фронт идёт к /api/weather, бэкенд внутри добавляет ключ и обращается к OpenWeather. Ключ живёт только на сервере.

Из этого правила есть смягчение: некоторые сервисы делят ключи на publishable (можно публиковать в JS) и secret (только на сервере). У Stripe, например, есть pk_* и sk_*; pk_* можно использовать на фронте, но он умеет только то, что не страшно отдать в чужие руки (создать токен карты, но не списать с неё деньги).

Что делать при утечке

Любой нормальный сервис позволяет отозвать ключ в один клик из админки. Алгоритм при подозрении на утечку:

1. Сразу сгенерировать новый ключ.
2. Подменить старый на новый везде, где он использовался.
3. Отозвать старый.
4. Проверить логи на подозрительную активность за период от утечки.

Хорошие сервисы поддерживают ротацию — одновременную работу старого и нового ключа в течение некоторого срока, чтобы не было даунтайма при подмене.

Краткая шпаргалка

Для чувствительных операций и для веб-приложений с пользовательскими сессиями нужны более изощрённые штуки — токены с истечением. О них — следующая глава.