Какие знаешь виды токенов?

Виды токенов в контексте тестирования и автоматизации

В QA Automation, особенно при тестировании API и веб-приложений, понимание видов токенов критически важно для построения корректных авторизационных сценариев и работы с защищёнными endpoints. Токены — это цифровые ключи, которые подтверждают права доступа без необходимости передавать учётные данные каждый раз.

Основные категории токенов

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

Это наиболее распространённый тип в OAuth 2.0 и OpenID Connect. Они предоставляют клиенту право доступа к защищённым ресурсам (API, данным пользователя).

• Характеристики:

    *   Короткий срок жизни (минуты, часы).
    *   Передаются в заголовке `Authorization: Bearer <token>`.
    *   Содержат **claims** (утверждения) о клиенте и правах доступа (scope).

// Пример декодированного JWT Access Token (секция payload)
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516242622,
  "scope": "read:profile write:posts"
}

2. Токены обновления (Refresh Tokens)

Используются для получения новых Access Tokens после истечения срока их действия, не требуя повторного ввода логина и пароля пользователем.

• Характеристики:

    *   Долгий срок жизни (дни, месяцы).
    *   Хранятся максимально безопасно (не в браузере, а в backend или защищённом хранилище мобильного приложения).
    *   Отправляются только на специальный эндпоинт токенов (`/token`).

# Пример запроса на обновление токена в автотесте (Python, requests)
import requests

refresh_response = requests.post('https://api.example.com/token',
                                 data={
                                     'grant_type': 'refresh_token',
                                     'refresh_token': 'very_long_refresh_token_string_here',
                                     'client_id': 'your_client_id'
                                 })
new_access_token = refresh_response.json()['access_token']

3. Идентификационные токены (ID Tokens)

Специфичны для OpenID Connect. Это JWT, которые содержат информацию о пользователе (claims) и предназначены для клиентского приложения, а не для доступа к ресурсам.

• Характеристики:

    *   Содержат claims о аутентификации пользователя (`iss`, `sub`, `aud`, `email`, `name`).
    *   Проверяются клиентом для установления сессии.

4. Токены CSRF (Anti-CSRF Tokens)

Используются для защиты от межсайтовой подделки запросов. Это случайные значения, генерируемые сервером и передаваемые в формах или через заголовки.

• Характеристики:

    *   Привязаны к пользовательской сессии.
    *   Часто передаются как скрытое поле в форме (`<input type="hidden" name="csrf_token" value="abc123">`) или в заголовке `X-CSRF-Token`.
    *   Обязательны для тестирования веб-форм в **UI** или **E2E**-автотестах.

# Пример извлечения CSRF-токена из формы и его использования в Selenium-тесте
from selenium.webdriver.common.by import By
import requests

# 1. Получить страницу с формой
driver.get("https://example.com/login")
# 2. Найти токен в скрытом поле
csrf_token = driver.find_element(By.NAME, "csrf_token").get_attribute("value")

# 3. Или получить из meta-тега
# csrf_token = driver.find_element(By.CSS_SELECTOR, "meta[name='csrf-token']").get_attribute("content")

# 4. Использовать токен при отправке POST-запроса (например, через API для подготовки данных)
headers = {'X-CSRF-Token': csrf_token}
requests.post('https://api.example.com/data', headers=headers, json={"key": "value"})

5. Токены для одноразовых операций (One-Time Tokens, OTT)

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

Практическое значение для QA Automation

1. Стратегия управления состоянием в тестах: Для интеграционных и API-тестов необходимо корректно получать, хранить (во время выполнения теста) и обновлять Access Token. Часто используется паттерн токен-менеджера или фабрики запросов с автоматической подстановкой токена.

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

    *   Проверка истечения срока действия **Access Token**.
    *   Валидация отзыва **Refresh Token**.
    *   Тесты на отсутствие доступа с поддельным или истёкшим токеном (должны возвращаться коды `401 Unauthorized` или `403 Forbidden`).
    *   Проверка корректности **scope** токена (пользователь с токеном только на `read` не должен иметь возможности выполнять `write`-операции).

1. Влияние на тест-дизайн: Сценарии должны учитывать необходимость предварительной аутентификации (получения токена) и реаутентификации (через refresh token) при долгих сессиях (например, в E2E-тестах). Работа с CSRF-токенами является обязательным этапом при автоматизации тестирования веб-форм.

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