Как тестировать авторизацию и токены API?

Manual QA Senior API / Backend обновлено 12.10.2025

Краткий ответ

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

Примеры проверок:
Успешный логин → выдаётся access-token (и при необходимости refresh-token).
Запрос с просроченным токеном → 401 Unauthorized.
Запрос без нужного scope/роли → 403 Forbidden.

Полный ответ

1) Что именно тестируем

  • Аутентификацию: Basic, API-key, Bearer/JWT, OAuth2/OIDC (Auth Code + PKCE), mTLS.

  • Авторизацию: роли/права (RBAC), scopes.

  • Жизненный цикл токена: выдача → использование → истечение (exp) → обновление (refresh) → отзыв/блокировка.

2) Позитивные сценарии

  1. Логин корректными данными → 200 OK + access_token (и refresh_token, если предусмотрен).

  2. Доступ с валидным access-token к защищённому ресурсу → 200 OK, корректные данные.

  3. Обновление токена по валидному refresh → новый access_token, корректные exp/iat.

  4. Scopes/роли: токен со scope payments:write может создавать платеж.

Пример (JWT Bearer):
GET /api/v1/payments с заголовком Authorization: Bearer <access_token> → 200 OK.

3) Негативные сценарии (обязательный минимум)

  • Неверные креды при логине → 401, без утечки деталей (“user not found” скрываем).

  • Без токена / пустой токен → 401.

  • Просроченный токен (exp в прошлом) → 401.

  • Недостаточные права/неверный scope → 403.

  • Повторное использование refresh (reuse) при ротации → блокировка сессии/всех токенов.

  • Подмена алгоритма/подписи JWT (защита от alg=none, неверный iss/aud) → 401.

  • Токен в URL (query) → запрещено, сервер отклоняет/логирует.

4) Проверки содержимого и политики токена

Для JWT проверяем клеймы:

  • iss, aud, sub — ожидаемые значения;

  • exp, nbf, iat — время, учитывая clock skew (например, ±60 сек);

  • scope/roles — соответствуют кейсу;

  • Подпись валидна, алгоритм только разрешённый (например, RS256/ES256).

Что ещё: разумный TTL (например, access 5–30 мин), короткий access + длинный refresh, шифрование транспорта (HTTPS обязателен), CORS/CSRF для cookie-based сценариев (HttpOnly, Secure, SameSite).

5) OAuth2/OIDC — что проверить отдельно

  • Authorization Code + PKCE для мобильных/SPA: корректность code_verifier/code_challenge.

  • Consent экран и выдача нужных scopes.

  • Token introspection/revocation — статус токена и его отзыв.

  • Logout: серверная инвалидизация сессии/refresh.

6) Рейт-лимиты и защита

  • Brute-force логина: лимиты, капча/заморозка учётки.

  • Rate limiting на чувствительные эндпойнты (/login, /token).

  • Replay-атаки: одноразовость кода авторизации, nonce в OIDC, ротация refresh.

7) Практические инструменты и приёмы

  • Postman/Insomnia: коллекции с pre-request скриптами (автологин → подставить токен), переменные окружений, тест-скрипты на коды/схемы.

  • Автотесты API: RestAssured / PyTest + JSON-схемы; мок/стаб внешних IdP при необходимости.

  • Проверка клеймов: библиотека для декодирования JWT (без доверия к payload, подпись валидируем!).

  • Логи/аудит: успешные/неуспешные входы, отозванные токены, IP/Device-binding (если есть).

8) Набор типовых кейсов (шпаргалка)

Аутентификация

  • ✅ Логин валидный → 200, есть access (+ refresh).

  • ❌ Логин невалидный → 401, унифицированное сообщение.

Доступ к ресурсу

  • ✅ Authorization: Bearer <valid> → 200.

  • ❌ Без токена → 401.

  • ❌ Токен просрочен → 401.

  • ❌ Нужен scope admin:*, у токена только read:* → 403.

Жизненный цикл

  • ✅ Refresh по валидному → новый access; старый access можно использовать до истечения (или сразу инвалидируется — по дизайну).

  • ❌ Reuse старого refresh после ротации → блок/алерт.

  • ✅ Отзыв (revocation) → любые дальнейшие запросы с этим токеном → 401.

JWT-валидность

  • ❌ Изменённый payload/подпись → 401.

  • ❌ aud/iss не совпадают с конфигом → 401.

  • ✅ nbf в будущем → 401 до наступления времени.

9) Пример запросов

Логин
POST /oauth/token

{ "grant_type": "password", "username": "user@test.com", "password": "Secret123!", "scope": "payments:read payments:write" }

Ожидание: 200 + { "access_token": "...", "expires_in": 1800, "refresh_token": "..." }.

Защищённый ресурс
GET /api/v1/payments + Authorization: Bearer <access> → 200.
С истёкшим токеном → 401 + семантичная ошибка (например, token_expired).

Refresh
POST /oauth/token

{ "grant_type": "refresh_token", "refresh_token": "<rt-123>" }

Ожидание: новый access_token; старый refresh — отозван (при ротации).

10) Частые проблемы и как их чинить

  • Флаки на времени → добавить допуск по времени (clock skew).

  • Хранение токена в LocalStorage → для SPA предпочитать cookie HttpOnly + CSRF-защиту.

  • Токен в URL → запретить, логировать инциденты.

  • Слишком общие ошибки или, наоборот, утечка деталей → баланс: информативно, без раскрытия внутренностей.

Итог:
Качественные тесты авторизации и токенов покрывают аутентификацию, права (scopes/ролей), жизненный цикл токенов, а также безопасность и устойчивость (лимиты, ротация, отзыв, защита от атак).

Оцените ответ
0 / 5 · 0

Related Questions