Как устроено взаимодействие API при авторизации?

Механизм авторизации через API: архитектура и практика

Авторизация в API — это процесс проверки прав доступа аутентифицированного пользователя или приложения к определенным ресурсам. В отличие от аутентификации (подтверждения личности), авторизация отвечает на вопрос «Что пользователь может делать?». Современные API используют несколько стандартизированных подходов.

Ключевые протоколы и методы авторизации

1. API Keys (Ключи API)

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

```http
GET /api/v1/users?api_key=sk_live_1234567890abcdef
Host: example.com
```

2. OAuth 2.0 и OpenID Connect (OIDC)

    *   **OAuth 2.0** — индустриальный стандарт для **делегированного доступа**. Позволяет приложению получать ограниченный доступ к ресурсам пользователя без передачи его логина и пароля.
    *   **OIDC** — надстройка над OAuth 2.0, добавляющая стандартизированную информацию об аутентификации пользователя (ID Token).
    *   Основные **потоки (grant types)**:
        *   **Authorization Code Flow** — для веб-серверов. Наиболее безопасный, включает код авторизации.
        *   **Implicit Flow** (устарел) — для одностраничных приложений (SPA).
        *   **Resource Owner Password Credentials** — для доверенных приложений (не рекомендуется).
        *   **Client Credentials** — для машин-машинного взаимодействия (M2M).

1. Токены доступа (Access Tokens) и JWT

    *   После успешной авторизации по OAuth клиент получает **токен доступа** (обычно в формате **JWT — JSON Web Token**).
    *   JWT — компактный, самодостаточный токен, содержащий **заявки (claims)** о пользователе и правах. Подписывается цифровой подписью.
    *   Клиент отправляет токен в заголовке `Authorization`.

```http
GET /api/v1/profile
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
```

    **Структура JWT:**

```json
// Header (алгоритм и тип токена)
{
  "alg": "HS256",
  "typ": "JWT"
}
// Payload (данные / claims)
{
  "sub": "1234567890",
  "name": "John Doe",
  "scopes": ["read:profile", "write:posts"],
  "iat": 1516239022
}
// Signature (подпись)
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
```

4. Серверы ресурсов (Resource Server) и проверка токенов

    *   Сервер, предоставляющий API (ресурс-сервер), должен проверять каждый входящий запрос с токеном.
    *   **Проверка включает:**
        *   Целостность и валидность подписи JWT.
        *   Срок действия токена (`exp` claim).
        *   Наличие необходимых **скопов (scopes)** или **ролей (roles)** для выполнения запрошенного действия.

Типичная последовательность (Authorization Code Flow)

graph LR
    A[Клиентское приложение] -->|1. Инициирует вход| B(Сервер авторизации /IdP);
    B -->|2. Перенаправляет на страницу входа| C[Пользователь];
    C -->|3. Вводит credentials| B;
    B -->|4. Перенаправляет с кодом| A;
    A -->|5. Обменивает код на токен| B;
    B -->|6. Возвращает Access & Refresh Token| A;
    A -->|7. Запрос к API с Access Token| D[Сервер ресурсов API];
    D -->|8. Валидирует токен| B;
    D -->|9. Возвращает данные| A;

Роль QA Engineer в тестировании авторизации API

1. Тестирование положительных и отрицательных сценариев:

    *   Успешный обмен кода на токен.
    *   Запросы с валидным/просроченным/неверным токеном.
    *   Проверка **скопов**: запрос к ресурсу без нужного scope должен вернуть `403 Forbidden`.

1. Тестирование безопасности:

    *   **Инъекции в токены или параметры авторизации.**
    *   Попытки **подмены (token tampering)** JWT.
    *   **CSRF** в flows, использующих редиректы.
    *   Утечка чувствительных данных в URL (код авторизации должен передаваться только в теле POST-запроса при обмене на токен).

1. Тестирование нагрузки и сроков действия:

    *   Как ведет себя система при множественных запросах на обновление токенов.
    *   Корректность работы **refresh tokens** и их отзыв.
    *   Валидация `exp`, `nbf` (not before) claims в JWT.

1. Инструменты:

    *   **Postman/Newman:** Настройка коллекций с автоматическим получением токенов.
    *   **JWT.io:** Декодирование и проверка структуры JWT.
    *   **OWASP ZAP/Burp Suite:** Проведение security-тестов.
    *   **Кастомные скрипты** на Python/JS для сложных сценариев.

Важно понимать, что выбор метода авторизации зависит от контекста: публичное API, микросервисная архитектура или доступ к пользовательским данным. Для QA критично не только проверять «счастливый путь», но и моделировать edge-кейсы и атаки, обеспечивая безопасность всего цикла взаимодействия.