Какие знаешь виды JWT Token?

JWT Token: виды и применение

JWT (JSON Web Token) — это стандарт для безопасной передачи информации между сторонами. Структурно любой JWT состоит из трех частей, разделенных точками: Header.Payload.Signature, но они различаются по назначению и используемым алгоритмам.

Основные виды JWT токенов

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

Это основной токен для авторизации запросов.

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

• Короткий срок жизни: обычно 15-60 минут
• Содержит информацию о пользователе и его правах (claims)
• Отправляется с каждым API запросом в header: Authorization: Bearer <token>
• Пример payload:

{
  "sub": "user-id-123",
  "email": "user@example.com",
  "role": "admin",
  "iat": 1704067200,
  "exp": 1704070800
}

Тестирование:

• Проверяю, что Access Token требуется для доступа к защищенным endpoints
• Если токен истек (exp < текущее время), API возвращает 401 Unauthorized
• Если токен поддельный или подпись неверная, API должен отклонить

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

Используется для получения нового Access Token без повторной аутентификации.

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

• Длительный срок жизни: дни или недели (7-30 дней)
• Более чувствительный, чем Access Token, потому что действует дольше
• Обычно хранится в HTTP-only cookie для безопасности
• Отправляется только при запросе к endpoint /refresh или /token
• Пример:

GET /api/auth/refresh
Cookie: refresh_token=<token>

Процесс обновления:

1. Frontend отправляет Refresh Token на сервер
2. Сервер проверяет токен
3. Если валидный, возвращает новый Access Token
4. Старый Access Token больше не нужен

Тестирование:

• Refresh Token не должен работать для доступа к API endpoints напрямую
• Когда Access Token истек, но Refresh Token еще валидный, система должна выдать новый Access
• Если Refresh Token истек, требуется повторная аутентификация (логин)

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

Используется в OpenID Connect (расширение OAuth 2.0).

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

• Содержит информацию о пользователе (идентификация)
• Короткий срок жизни: как Access Token
• Может содержать: name, email, picture, phone и другие профильные данные
• Пример payload:

{
  "iss": "https://auth.example.com",
  "sub": "user-id-123",
  "aud": "client-id",
  "name": "John Doe",
  "email": "john@example.com",
  "picture": "https://example.com/photo.jpg",
  "iat": 1704067200,
  "exp": 1704070800
}

Различие от Access Token:

• Access Token — для авторизации (что пользователь может делать)
• ID Token — для идентификации (кто этот пользователь)

Тестирование:

• Проверяю, что ID Token содержит корректную информацию пользователя
• При изменении профиля пользователя, новый ID Token должен содержать обновленные данные

Структура JWT

Независимо от типа, все JWT состоят из:

Header:

{
  "alg": "HS256",
  "typ": "JWT"
}

• alg — алгоритм подписи (HS256, RS256, ES256 и т.д.)
• typ — тип токена

Payload:

• Пользовательские данные (claims)
• iat (issued at) — время создания
• exp (expiration) — время истечения
• sub (subject) — ID пользователя
• Кастомные claims: role, permissions и т.д.

Signature:

• Цифровая подпись, созданная с помощью Header + Payload + Secret
• Проверяет, что токен не был изменен

Алгоритмы подписи

HS256 (HMAC SHA-256)

• Симметричный алгоритм (один секретный ключ)
• Используется на одном сервере
• Быстро, но менее безопасно для микросервисов

RS256 (RSA + SHA-256)

• Асимметричный алгоритм (приватный и публичный ключи)
• Подходит для микросервисной архитектуры
• Auth сервер подписывает (приватный ключ), другие сервисы проверяют (публичный ключ)

ES256 (ECDSA + SHA-256)

• Более современный, компактнее чем RS256
• Меньший размер подписи

Тестирование безопасности JWT

1. Проверка срока действия:

• Использую токен с истекшим exp — должна быть ошибка 401
• Использую токен с будущим exp (более чем на допустимый период) — должна быть ошибка

2. Проверка подписи:

• Изменяю payload токена, но оставляю старую подпись — должна быть ошибка
• Меняю alg на "none" для обхода проверки — должна быть ошибка (уязвимость!)

3. Проверка данных:

• Токен не должен содержать пароли
• Чувствительные данные должны быть зашифрованы

4. Проверка обновления:

• Access Token истек, отправляю Refresh Token — получаю новый Access Token
• Refresh Token заблокирован (например, пользователь вышел) — получаю ошибку

Типичные уязвимости

Token Confusion:

• Использование Access Token как Refresh Token
• Система неправильно проверяет тип токена

Signature Bypass:

• Сервер принимает токены без подписи (alg: none)
• Использование слабого секретного ключа

Token Leakage:

• Токен передается в URL вместо headers
• Токен логируется в логах или отправляется в третьи сервисы

Практический пример тестирования

import requests
import json
from base64 import b64decode

token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

# Декодирую payload
parts = token.split(.)
payload = json.loads(b64decode(parts[1] + ==))
print(payload)  # {"sub": "user-123", "exp": 1704070800}

# Проверяю, истек ли токен
import time
if payload[exp] < time.time():
    print("Token expired")

# Отправляю запрос с токеном
headers = {"Authorization": f"Bearer {token}"}
response = requests.get("/api/protected", headers=headers)
print(response.status_code)  # 200 если валидный, 401 если истек

Итог

Для QA-инженера важно понимать различия между Access, Refresh и ID токенами, уметь их декодировать, проверять срок действия и тестировать различные сценарии обновления и компрометации. Это критично для тестирования аутентификации и авторизации в современных приложениях.