Какие данные можно хранить в JWT-токене

Данные для хранения в JWT-токене

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

Основные типы данных в Payload

В Payload можно хранить два типа данных:

1. Registered Claims — стандартизированные, предопределенные поля, рекомендованные RFC 7519.
2. Public Claims — произвольные, пользовательские поля, определенные разработчиками.

Registered Claims (Стандартизированные данные)

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

{
  "iss": "auth.example.com",
  "sub": "user12345",
  "aud": "api.example.com",
  "exp": 1719925200,
  "nbf": 1719921600,
  "iat": 1719921600,
  "jti": "a1b2c3d4-e5f6-7890"
}

• iss (Issuer) — идентификатор эмитента токена (например, сервис авторизации).
• sub (Subject) — идентификатор субъекта (пользователя), для которого выпущен токен.
• aud (Audience) — целевая аудитория токена (например, конкретный сервис или API).
• exp (Expiration Time) — время истечения токена в Unix timestamp. Это ключевое поле для безопасности.
• nbf (Not Before) — время, с которого токен начинает быть действительным.
• iat (Issued At) — время выпуска токена.
• jti (JWT ID) — уникальный идентификатор токена, помогает предотвратить replay-атаки.

Public Claims (Пользовательские данные)

Это данные, которые вы определяете сами для нужд вашего приложения. Их следует выбирать осторожно.

{
  "userId": 42,
  "username": "alexey",
  "roles": ["user", "content_moderator"],
  "email": "alexey@example.com",
  "preferences": {
    "theme": "dark",
    "locale": "ru_RU"
  },
  "department": "QA"
}

Какие пользовательские данные стоит хранить:

• Идентификаторы: userId, username.
• Привилегии и доступ: roles, permissions, scopes. Это позволяет реализовать авторизацию на уровне API-эндпоинтов.
• Контекстная информация для UI/UX: preferences, locale.
• Бизнес-контекст (для микросервисов): department, projectId — помогает в маршрутизации запросов или адаптации логики.

Какие данные НЕЛЬЗЯ хранить в JWT

JWT не является механизмом для безопасного хранения секретной информации. Он лишь подписан или зашифрован, но содержимое легко читается, если токен перехвачен.

• Секреты: Пароли, приватные ключи, токены доступа к другим системам.
• Критически важная бизнес-информация: Номер банковской карты, PII (Personal Identifiable Information) в избыточном объеме.
• Большие объемы данных: JWT передается в каждом запросе, часто в заголовке. Его размер напрямую влияет на нагрузку. Не храните большие списки или глубокие объекты.
• Чрезмерно детализированные права: Вместо списка 100 отдельных правомерностей ("canEditPost_123", "canDeletePost_456") используйте более высокоуровневые роли ("content_manager") и проверяйте детализированные права на сервере по userId.

Практические рекомендации для QA Engineer

Как QA, вы должны понимать эти принципы для составления эффективных тест-кейсов:

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

    *   Проверьте, что токен содержит поле **`exp`** и срок его жизни не слишком велик.
    *   Убедитесь, что в токене **нет** чувствительной информации (например, email в открытом виде, если это не требуется фронтенду).
    *   Проверьте реакцию системы на токен с измененным (подделанным) `role` — права должны проверяться сервером.

1. Тестирование функциональности:

    *   Проверьте, что ключевые пользовательские данные (`userId`, `roles`) корректно используются бэкендом для предоставления доступа.
    *   Проверьте, что UI корректно использует данные из токена (например, отображает `username` или применяет `theme`).

1. Тестирование производительности:

    *   Оцените размер токена. Он должен быть компактным. Большие токены могут привести к проблемам, если они передаются в каждом HTTP-заголовке.

Итог: В JWT храните минимально необходимый набор идентификационных и авторизационных данных (sub, roles), технические метки времени (exp, iat) и немного контекста для клиента. Все остальное — особенно детализированные данные и секреты — должно храниться и проверяться на защищенном сервере. Ваша задача как QA — убедиться, что этот баланс соблюдается, а токен используется безопасно.