Перейти на PRO

Какие основные виды аутентификации в API?

Тип вопроса: API тестирование Вероятность: 10% Категория: QA Тестировщик

Ответ

Основные методы аутентификации для API:

  1. API Keys

    • Применение: Простая аутентификация сервисов, ботов или для предоставления доступа к публичным API с ограничениями по тарифу.
    • Способ передачи: В заголовке (X-API-Key, Authorization: ApiKey) или как параметр запроса (?api_key=...).
    • Пример: 
      curl -H "X-API-Key: 12345abcde" https://api.example.com/data
    • Почему это важно: Параметр в URL может попасть в логи, поэтому предпочтительнее заголовок. Ключ должен храниться в секрете, как пароль.

  2. OAuth 2.0 Client Credentials Flow

    • Применение: Для аутентификации машин (M2M), когда приложение запрашивает доступ к своим собственным ресурсам, а не к данным пользователя.
    • Как работает: Приложение использует свои client_id и client_secret для получения access_token.

    • Пример запроса на токен:

      POST /oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Basic BASE64(client_id:client_secret)

grant_type=client_credentials

  3. JSON Web Tokens (JWT) как Bearer Tokens

    • Применение: Stateless-аутентификация. Часто используется после начальной аутентификации по OAuth 2.0 или логину/паролю.
    • Способ передачи: В заголовке Authorization: Bearer <token>.
    • Пример структуры JWT: 
      // Header
{"alg": "HS256", "typ": "JWT"}
// Payload (claims)
{"sub": "user123", "role": "admin", "exp": 1672531200}
// Signature
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
    • Почему это важно: Серверу не нужно хранить состояние сессии, достаточно проверить подпись токена и его claims (например, срок действия exp).

  4. HTTP Basic Authentication

    • Применение: Для простых сценариев, внутренних API или с прокси-серверами.
    • Пример: 
      curl -u "username:password" https://api.example.com/resource

  5. HMAC (Hash-based Message Authentication Code)

    • Применение: Для обеспечения целостности и аутентичности запроса. Клиент подписывает запрос (например, хешируя метод, путь, тело и timestamp с помощью секретного ключа).
    • Почему это важно: Защищает от перехвата и изменения запроса. Используется в API AWS S3, многих платежных системах.

Критерии выбора:

  • API Keys: Для простоты и сервис-сервисного взаимодействия.
  • OAuth 2.0: Когда нужен делегированный доступ к данным пользователя или безопасная M2M-аутентификация.
  • JWT: Для производительных, stateless API.
  • HMAC: Для максимальной безопасности и гарантии целостности запросов.

Ответ 18+ 🔞

Давай разберём эту пиздатую кухню аутентификации, как будто объясняю за бутылкой пива после тяжёлого дебага. Запоминай, а то потом будешь как Герасим — «Му-му» говорить, а нихуя не понимать.

1. Ключи от API (API Keys) Это как ключ от почтового ящика в подъезде. Просто, но если потеряешь — соседи спамом завалят.

  • Куда тыкать: В заголовок (X-API-Key) или в URL как параметр (?api_key=твой_секрет).
  • Пример: 
    curl -H "X-API-Key: 12345abcde" https://api.example.com/data
  • Важный момент, блядь: Если сунешь ключ в URL, он навеки останется в логах и истории браузера. Это как оставить отпечатки на месте преступления. Всегда пихай в заголовок! И храни этот ключ, как паспорт — в тайне.

2. OAuth 2.0 для машинок (Client Credentials Flow) Это когда две твои железяки (сервисы) должны по-честному договориться между собой, без участия юзера.

  • Как работает: У тебя есть client_id (это как лицо) и client_secret (это как подпись). Ты ими машешь перед сервером авторизации, а он в ответ выдает access_token — временный пропуск.

  • Пример, как попросить пропуск:

    POST /oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Basic BASE64(client_id:client_secret)

grant_type=client_credentials

3. JWT (JSON Web Tokens) А это, блядь, крутая штука. Stateless, то есть серверу не нужно помнить тебя. Ты просто предъявляешь токен, как билет в метро.

  • Как передать: В заголовке Authorization: Bearer <тут_твой_токен>.
  • Из чего состоит этот билет: 
    // Шапка (Header)
{"alg": "HS256", "typ": "JWT"}
// Тело (Payload) — тут вся информация о тебе
{"sub": "user123", "role": "admin", "exp": 1672531200}
// Подпись (Signature) — чтобы не подделали
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
  • В чём соль: Сервер смотрит на подпись, проверяет срок годности (exp) и — вуаля — ты в домике. Никаких сессий на сервере, чистая магия.

4. HTTP Basic Authentication Старый, добрый и дохуя простой способ. Как крикнуть в окно: «Вася, это я!».

  • Пример: 
    curl -u "username:password" https://api.example.com/resource
  • Где сгодится: Для внутренних дел, тестовых стендов или когда всё идёт через защищённый VPN. В открытом поле — самоубийство, потому что логин с паролем летят просто в base64, который раскодируется за полсекунды.

5. HMAC (Hash-based Message Authentication Code) Вот это, ёпта, уровень параноика. Ты не просто предъявляешь ключ, ты каждому запросу ставишь цифровую печать.

  • Суть: Берёшь метод запроса, путь, тело, timestamp, хуяришь это всё через секретный ключ и получаешь хеш (подпись). Эту подпись отправляешь вместе с запросом.
  • Зачем это надо: Чтобы никто не мог перехватить и подменить твой запрос. Даже если увидят всё — без твоего секретного ключа правильную подпись не сгенерируют. Так работает, например, AWS S3.

Так какую же хуйню выбрать?

  • API Keys — когда нужно просто и быстро, для сервисов или ботов.
  • OAuth 2.0 — когда твоё приложение лезет в данные пользователя от его имени (делегированный доступ) или когда две твои backend-железки дружат.
  • JWT — когда хочется скорости и масштабируемости, чтобы сервер не грузился хранением сессий.
  • HMAC — когда безопасность на первом месте и нужно гарантировать, что запрос не подделали. Для финансовых или критичных штук.
  • HTTP Basic — для внутренней кухни, где все свои и сеть под контролем.

Выбирай с умом, а то получится как в той истории: «Ядрёна вошь, опять токен просрочился!».

© ХакСобесов, 2026
support@hacksobesov.com