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

2.3 Middle🔥 183 комментариев

#Клиент-серверная архитектура

Комментарии (3)

🐱

deepseek-v3.2PrepBro AI5 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Основные виды токенов в информационной безопасности и тестировании

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

1. Токены аутентификации и авторизации

Это наиболее частый вид, с которым сталкивается QA-инженер при тестировании.

Токены сессии (Session Tokens): Обычно представляют собой идентификатор сессии (Session ID), который сервер генерирует после успешного входа пользователя. Этот ID хранится в куках (Cookies) браузера и отправляется с каждым запросом для идентификации сессии на сервере.
```
// Пример: Кука с Session ID (часто называется 'sessionid' или 'JSESSIONID')
// HTTP-заголовок в запросе
Cookie: sessionid=abc123def456ghi789; Path=/; HttpOnly
```

    **Тестирование**: Проверка срока жизни, безопасной передачи (HTTPS), атрибутов (`HttpOnly`, `Secure`, `SameSite`), инвалидации после выхода.

JWT (JSON Web Tokens): Современный стандарт (RFC 7519) для создания самодостаточных токенов доступа. Состоит из трёх частей, закодированных в Base64URL: Header, Payload и Signature.

// Пример структуры декодированного JWT
// Header: { "alg": "HS256", "typ": "JWT" }
// Payload: { "sub": "12345", "username": "johndoe", "exp": 1735689600 }
// Signature: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

    JWT передаётся в заголовке `Authorization: Bearer <token>`. Он позволяет клиенту хранить информацию (claims) и не требует постоянных проверок в базе данных сервера.
    **Тестирование**: Валидация подписи, проверка claims (например, `exp` — expiration time), уязвимости (например, изменение алгоритма подписи на `none`).

OAuth 2.0 / OpenID Connect (OIDC) Токены:

    *   **Access Token**: Токен доступа, который клиентское приложение использует для вызова защищённых API ресурсного сервера. Имеет ограниченный срок жизни и scope (область прав).
    *   **Refresh Token**: Долгоживущий токен, используемый для получения нового Access Token'а без повторного ввода учётных данных пользователем. Хранится максимально безопасно.
    *   **ID Token** (специфичен для OIDC): JWT, содержащий информацию о пользователе (claims), предназначен для клиентского приложения.

    **Тестирование**: Проверка корректности flow (Authorization Code, Implicit, etc.), сроков действия токенов, безопасности хранения Refresh Token, корректности работы scopes.

2. Токены безопасности от атак CSRF (Cross-Site Request Forgery)

CSRF-токены (Anti-CSRF Tokens): Уникальные, секретные, непредсказуемые значения, генерируемые сервером для каждой пользовательской сессии или формы. Встраиваются в формы как скрытые поля (<input type="hidden" name="csrf_token" value="abc123">) и проверяются сервером при отправке POST-запроса.

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

3. Токены для одноразовых операций

Токены для сброса пароля / подтверждения email (One-Time Password / OTP Tokens): Короткоживущие цифровые или буквенно-цифровые коды, отправляемые по SMS, email или генерируемые в приложении-аутентификаторе (Google Authenticator). Используются для подтверждения личности при критичных операциях.

    **Тестирование**: Проверка срока жизни (обычно 5-15 минут), одноразовости, стойкости к brute-force (лимит попыток), безопасной доставки.

4. Токены в платежных системах (Payment Tokens)

Платёжные токены: Заменяют конфиденциальные данные платежной карты (PAN, CVV) уникальным идентификатором. Используются для повторных транзакций, минимизируя риски. Пример: Tokenization в PCI DSS.

    **Тестирование**: Проверка, что исходные данные карты не сохраняются в системе, корректность подмены токена на данные при взаимодействии с платёжным шлюзом.

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

Понимание видов токенов позволяет строить эффективные стратегии тестирования:

Тестирование API: Работа с заголовками Authorization, Cookie. Написание автотестов для сценариев аутентификации.

# Пример запроса с JWT в Python (requests)
import requests
headers = {'Authorization': 'Bearer eyJhbGciOiJIUzI1NiIs...'}
response = requests.get('https://api.example.com/data', headers=headers)

Нагрузочное тестирование (Load Testing): Эмуляция работы тысяч пользователей требует корректного получения и использования токенов (сессий, JWT) в виртуальных сценариях.
Тестирование безопасности (Security Testing):

    *   Проверка утечки токенов в логах или URL.
    *   Попытки использовать просроченный, изменённый или токен другого пользователя (**Insecure Direct Object References - IDOR**).
    *   Проверка **JWT на уязвимости** с помощью инструментов вроде `jwt_tool`.
    *   Валидация корректной инвалидации токенов при выходе (logout).

Автоматизация UI-тестов: Поиск и взаимодействие с CSRF-токенами в формах, сохранение токенов сессии между шагами теста.

Таким образом, токены — это фундаментальный механизм управления состоянием и безопасностью в современных приложениях. Для QA-инженера важно не только знать их виды, но и понимать, как их корректно тестировать, имитировать и валидировать на всех уровнях тестирования.

🐱

deepseek-v3.2PrepBro AI5 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Виды токенов в аутентификации и их применение

В контексте авторизации и аутентификации (особенно в QA-тестировании API, веб- и мобильных приложений) токены — это цифровые ключи, которые подтверждают права доступа пользователя. Основные виды:

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

Краткосрочные токены, используемые клиентом для доступа к защищённым ресурсам API.

Формат: Обычно JWT (JSON Web Token), но может быть непрозрачной строкой.
Срок жизни: Короткий (минуты/часы).

Пример в заголовке HTTP:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

    *Где `eyJhbGciOiJ...` — сам токен.*

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

Долгоживущие токены, используемые для получения новой пары access/refresh tokens без повторного ввода учётных данных.

Хранение: Безопасное (HTTP-only cookie, secure storage на мобильном).
Сценарий: Истёкший access token → отправляем refresh token на эндпоинт /refresh → получаем новые токены.

Пример запроса на обновление:

POST /api/v1/auth/refresh HTTP/1.1
Content-Type: application/json

{
    "refresh_token": "def50200f3c...",
    "grant_type": "refresh_token"
}

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

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

Формат: Всегда JWT.
Содержание: iss (издатель), sub (ID пользователя), email, name и др.

Пример payload JWT:

{
    "iss": "https://auth.your-domain.com",
    "sub": "1234567890",
    "name": "John Doe",
    "email": "john@example.com",
    "iat": 1516239022,
    "exp": 1516242622
}

4. Bearer Tokens

Это не отдельный вид, а способ использования токена (чаще Access Token). Ключевой принцип: "предъявитель токена" (Bearer) получает доступ. Уязвим к перехвату — требует HTTPS.

5. CSRF Tokens (Токены защиты от межсайтовой подделки запроса)

Секретные уникальные значения, защищающие state-changing операции (POST, PUT, DELETE) в веб-приложениях.

Генерация: Сервером, прикладывается к форме.
Проверка: Сервер сравнивает токен из формы и токен из сессии.

Пример в HTML-форме:

<form action="/transfer" method="POST">
    <input type="hidden" name="csrf_token" value="a1b2c3d4e5f6">
    <!-- другие поля формы -->
</form>

6. API Keys (API-ключи)

Статические токены для идентификации приложения или сервиса (не пользователя). Часто для доступа к публичным API.

Передача: В заголовке или как query-параметр.

Пример:

GET /api/v1/data?api_key=sk_live_123abc HTTP/1.1

7. Session Tokens (Токены сессии / Session ID)

Идентификатор сессии пользователя, обычно хранится в cookie.

Альтернатива: Хранение session ID в локальном хранилище с передачей в заголовке.

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

Понимание этих токенов критично для:

Тестирования безопасности: Проверка срока жизни, валидации, защиты refresh токенов, устойчивости к CSRF.
Отладки API: Анализ запросов в инструментах типа Postman, Charles Proxy.
Написания автотестов: Корректная работа с аутентификацией в Selenium, Playwright, Cypress или скриптах на Python (requests), JavaScript.

Пример скрипта для получения Access Token (OAuth 2.0 Resource Owner Password Credentials):

import requests

auth_url = "https://auth.server.com/oauth/token"
data = {
    'grant_type': 'password',
    'username': 'test_user',
    'password': 'test_pass',
    'client_id': 'your_client_id',
    'client_secret': 'your_client_secret'
}

response = requests.post(auth_url, data=data)
tokens = response.json()
access_token = tokens['access_token']
refresh_token = tokens.get('refresh_token')

# Использование access_token для вызова API
api_url = "https://api.server.com/v1/protected"
headers = {'Authorization': f'Bearer {access_token}'}
api_response = requests.get(api_url, headers=headers)
print(api_response.json())

Ключевые проверки в тестировании:

Истекает ли access token корректно?
Отзывает ли система access token при logout?
Можно ли использовать украденный access token с другого IP?
Защищены ли refresh tokens от повторного использования?
Валидируется ли подпись JWT на стороне сервера?
Не передаётся ли токен в логах или ошибках приложения?

Это знание позволяет не только выполнять ручные проверки, но и проектировать надёжные автоматизированные тестовые сценарии для критически важных потоков аутентификации.