Базовая аутентификация против токенов Bearer Какой метод аутентификации API использовать

Каждый запрос к API должен подтвердить, кто его отправляет. Метод, который вы выбираете, определяет вашу безопасность, опыт разработчика и операционную нагрузку на годы. Базовая аутентификация, API-ключи, токены Bearer и OAuth решают разные задачи — и использование неправильного метода создаёт долгосрочные проблемы, которые трудно устранить. Ниже приведена ясная разбивка каждого из них, с кодом, который можно скопировать, и таблицей принятия решений, чтобы вы могли выбрать подходящий вариант для своей ситуации.

HTTP Базовая аутентификация

Базовая аутентификация отправляет учетные данные с каждым запросом. Клиент объединяет имя пользователя и пароль как username:password, кодирует строку в формате Base64 и помещает в заголовок Authorization :

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Эта строка Base64 является не зашифрованы. Любой, кто перехватывает запрос, может её декодировать за несколько секунд. Базовая аутентификация безопасна только при использовании HTTPS, и даже тогда учетные данные передаются с каждым запросом и попадают в логи сервера, если вы не активно удаляете их.

Чтобы сгенерировать правильное значение заголовка без ручного кодирования учетных данных, используйте генератор IO Tools генератор базовой аутентификации.

# curl with Basic Auth
curl -u username:password https://api.example.com/data

# Or with the explicit header
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

// fetch with Basic Auth
const credentials = btoa('username:password');
fetch('https://api.example.com/data', {
  headers: { Authorization: `Basic ${credentials}` }
});

Когда это допустимо: Внутренние инструменты, разработочные среды и простые интеграции между серверами, где вы контролируете оба конца. Никогда не использовать для публичных API или аутентификации пользователей.

API-ключи

API-ключ — это статический токен — длинная случайная строка, привязанная к определенному приложению или вызывающему. Клиент отправляет его в заголовке, обычно в X-API-Key или в заголовке Authorization с собственной схемой:

# curl with API key
curl -H "X-API-Key: sk_live_abc123xyz" https://api.example.com/data

# Or with Authorization header
curl -H "Authorization: ApiKey sk_live_abc123xyz" https://api.example.com/data

// fetch with API key
fetch('https://api.example.com/data', {
  headers: { 'X-API-Key': 'sk_live_abc123xyz' }
});

API-ключи легко реализуются и немедленно могут быть отозваны при утечке. Недостаток: они являются безсостоятельными и не имеют встроенной срока действия. Утечка ключа остаётся действительной до тех пор, пока вы не отозвали его вручную. Нет подписи для проверки и нет встроенной области действия — только строку, которую нужно искать в базе данных.

Когда их использовать: Интеграции с третьими сторонами, продукты API для разработчиков и публичный доступ к API, где вы хотите настроить ограничение скорости на уровне клиента и немедленное отзывание без дополнительных затрат OAuth.

Токены Bearer (JWT)

Токены Bearer — чаще всего JWT (JSON Web Tokens) — выдаются аутентификационным сервером и отправляются в заголовок Authorization с схемой Bearer :

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

JWT содержит подписанную нагрузку, содержащую утверждения: кто пользователь, какие у него права и когда токен истекает. Сервер проверяет токен, подтверждая подпись с помощью общего секрета или публичного ключа — не требуется обращение к базе данных. Эта безсостоятельная проверка является главным преимуществом в распределённых системах и архитектурах микросервисов.

Существуют реальные компромиссы: JWTы большие (несколько сотен байт на запрос), и они не могут быть отменены до истечения срока действия без дополнительной инфраструктуры, такой как список заблокированных токенов. Ошибки при реализации — слабые секреты подписи, отсутствие проверки срока действия, атаки из-за неясности алгоритма — вызвали серьёзные утечки в рабочих системах.

# curl with Bearer token
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  https://api.example.com/data

// fetch with Bearer token
fetch('https://api.example.com/data', {
  headers: { Authorization: `Bearer ${token}` }
});

Когда их использовать: Пользовательские API, микросервисы, которые должны передавать идентичность дальше, и любые сценарии, где кратковременные учетные данные с встроенными утверждениями снижают необходимость в серверной сессионной статике.

OAuth 2.0: Токены доступа и токены обновления

OAuth 2.0 не является форматом токена — это протокол делегирования. Когда ваше приложение должно действовать от имени пользователя и получать доступ к ресурсам на другом сервисе, OAuth 2.0 управляется согласием и обменом токенов.

Краткое описание потока: пользователь даёт согласие, а сервер авторизации выдаёт кратковременный токен доступа и долговременный токен обновления, ваше приложение использует токен доступа для вызовов API, и когда токен доступа истекает, токен обновления обменивается на новый без повторного запроса у пользователя.

# Step 1: Exchange credentials for a token (client credentials flow)
curl -X POST https://auth.example.com/token \
  -d "grant_type=client_credentials" \
  -d "client_id=myapp" \
  -d "client_secret=mysecret"

# Step 2: Use the access token
curl -H "Authorization: Bearer ACCESS_TOKEN" https://api.example.com/data

# Step 3: Refresh when expired
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=REFRESH_TOKEN" \
  -d "client_id=myapp"

Токены доступа обычно являются JWT. Токены обновления — это прозрачные строки, хранящиеся на сервере — никогда не передавайте их клиентским кодам.

Когда это нужно: Социальные входы, доступ к данным третьих сторон, любая интеграция «Войти с X» или любая ситуация, где человек должен дать согласие на то, что ваше приложение может делать от его имени.

Правила безопасности, применимые ко всем методам

Независимо от выбранного метода аутентификации, эти правила применяются без исключений.

• HTTPS везде. Учётные данные или токены при передаче по обычному HTTP уязвимы моментально, когда кто-то может просмотреть пакет. Нет исключений.
• Никогда не храните секреты в коде. Используйте переменные среды или менеджер секретов. Никаких учётных данных в контролируемых файлах — включая файлы, исключённые из .gitignore, поскольку такие исключения не являются надёжными на практике.
• Повторяйте по расписанию и при подозрении. API-ключи должны быть поворачиваемы без простоя. Секреты подписи JWT должны поддерживать версионирование, чтобы вы могли поворачивать их без отмены всех активных сессий одновременно.
• Самая короткая продолжительность, которая работает. Токены доступа: минуты до нескольких часов. API-ключи: поворачивайте при любом изменении персонала. Учётные данные базовой аутентификации: рассматривайте как привилегированные и поворачивайте активно.
• Проверяйте, кто имеет что. Поддерживайте реестр выданных учётных данных. Когда что-то пошло не так, вам нужно знать, что именно было выдано, кому и когда.

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

Метод	Безсостоятельный	Отзываемый	Сложность	И ни один из вариантов не является универсально лучшим. JWT отлично справляется с аутентификацией без состояния в нескольких сервисах. Токены сессий проще, когда вы контролируете всю структуру и нуждаетесь в мгновенной отмене (например, «выход во всех приложениях» в случае безопасности).
Базовая аутентификация	Да	Только путём изменения учётных данных	Очень низкий	Внутренние инструменты, среда разработки
API-ключ	Да	Да, немедленно	Низкий	Интеграции с третьими сторонами, API для разработчиков
Bearer (JWT)	Да	Только с помощью списка заблокированных токенов	Середина	Пользовательские API, микросервисы
OAuth 2.0	Варьируется	Да	Высокий	Делегирование пользователя, аутентификация третьих сторон

Внутренний API, сервер-к-серверу, без пользователей: API-ключи. Просто в реализации, немедленно отзываемы, легко аудитируются. Если вы уже работаете с микросервисами, использующими JWT, используйте кратковременный токен сервисного аккаунта вместо этого.

Публичный API с внешними потребителями-разработчиками: API-ключи с ограничениями скорости на уровне ключа и порталом самоуправления. Добавьте OAuth-области, если потребители хотят запрашивать доступ к определённым ресурсам от имени своих пользователей.

Аутентификация пользователей в вашем продукте: Токены Bearer (JWT) с коротким сроком действия и вращением токена обновления. Выдавайте токены после проверки учётных данных, делайте их кратковременными и избегайте хранения в localStorage если в вашем приложении существует риск XSS.

Доступ к сервису третьей стороны от имени одного из ваших пользователей: Протокол авторизации OAuth 2.0. Не упрощайте этот процесс. Модель делегирования пользователя существует потому, что это самый безопасный способ обработки согласия от третьих сторон на масштабе.

Правильный выбор обычно определяется двумя вопросами: кто является вызывающим и нужна ли согласие человека на то, что делает вызывающий. Если вызывающий — это машина и нет делегирования пользователя, API-ключи решают большинство случаев. Добавьте JWT, когда вам нужно встроенные утверждения или безсостоятельная идентичность между сервисами. Используйте OAuth только тогда, когда согласие пользователя является частью потока.

Вам также может понравиться