Где передаётся токен?

Механизмы передачи токенов (Token Transfer Mechanisms)

В контексте тестирования веб-приложений и API, токен (чаще всего JWT — JSON Web Token) обычно передаётся для аутентификации и авторизации пользователя. Место и способ передачи зависят от архитектуры приложения и протокола. Основные методы:

1. HTTP-заголовки (HTTP Headers)

Наиболее распространённый и безопасный способ.

• Authorization Header (Стандарт де-факто для REST API):

    Токен передаётся в заголовке `Authorization`, чаще всего с префиксом `Bearer`.

```http
GET /api/users/profile HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
```

• Custom Headers (Пользовательские заголовки):

    Иногда используются свои заголовки, например `X-Access-Token` или `X-API-Key`. Этот подход менее стандартизирован.

```http
POST /api/data HTTP/1.1
Host: example.com
X-API-Token: abc123def456ghi789
```

2. Cookies

Часто используется в традиционных веб-приложениях с серверным рендерингом (SSR) или для механизмов сессий и refresh token.

• Сервер устанавливает токен в cookie через заголовок Set-Cookie в ответе, и браузер автоматически отправляет его с каждым последующим запросом к тому же домену.

• Для защиты от атак (CSRF, XSS) используются флаги: HttpOnly, Secure, SameSite.

  HTTP/1.1 200 OK
  Set-Cookie: session_token=eyJhbGci...; HttpOnly; Secure; SameSite=Strict
  

3. Тело запроса (Request Body)

Менее распространённый и не самый безопасный метод, обычно используется только для первоначального получения токена (например, при логине) или в специфичных протоколах.

```json
POST /auth/login HTTP/1.1
Content-Type: application/json

{
  "username": "user@example.com",
  "password": "secret",
  "token": "some_one_time_code" // Например, для 2FA
}

### 4. **Параметры URL (Query Parameters)**
Самый небезопасный метод, так как токен может попасть в логи серверов, историю браузера, referrer.

*   **Использовать не рекомендуется**, кроме специфичных случаев (например, скачивание файлов по защищённой ссылке или вызовы из сред, где нельзя установить заголовки).

    ```
    GET /api/download-report?fileId=123&access_token=eyJhbGci... HTTP/1.1
    Host: example.com
    ```

### С точки зрения QA Engineer: на что обращать внимание при тестировании?

1.  **Безопасность передачи:**

*   При использовании **Bearer token** в заголовке `Authorization` все запросы должны идти по **HTTPS (TLS)**.
*   Проверять, не передаётся ли токен в URL (query string) в штатных сценариях.
*   Если токен в cookie — проверять наличие атрибутов безопасности (`HttpOnly`, `Secure`, `SameSite`).

2.  **Хранение на клиенте (Frontend):**

*   Для SPA (Single Page Application) **access token** часто хранится в памяти или **sessionStorage** (исчезает при закрытии вкладки) / **localStorage** (сохраняется). Нужно тестировать сценарии истечения срока действия токена (expiry).
*   **Refresh token**, если используется, должен храниться максимально безопасно (предпочтительно в `HttpOnly` cookie).

3.  **Механизм обновления токенов (Refresh Flow):**

*   Критически важный для тестирования сценарий: что происходит, когда **access token** истёк? Приложение должно автоматически, используя **refresh token**, получить новую пару токенов без принудительного логина пользователя.
*   Нужно тестировать инвалидацию refresh token при повторном использовании.

4.  **Инструменты для проверки:**

*   **Вкладка Network** в браузере (Chrome DevTools, Firefox Developer Tools) — смотрим заголовки запросов.
*   **Postman / Insomnia** — настраиваем автоматическую отправку токена в коллекциях.
*   **Burp Suite / OWASP ZAP** — для углублённого анализа безопасности и перехвата трафика.

**Вывод для QA:** Понимание, *где* и *как* передаётся токен, позволяет целенаправленно тестировать **безопасность** (уязвимости передачи), **функциональность** (доступ к защищённым эндпоинтам) и **удобство использования** (сценарии истечения сессии, multiple tabs). Всегда сверяйся с документацией API (Swagger/OpenAPI), чтобы знать ожидаемый метод аутентификации для каждого endpoint.