Перейти к основному содержимому

[Lv1] Какова структура JWT?

Интервьюеры часто задают уточняющий вопрос: «Как выглядит JWT? Почему он спроектирован именно так?» Понимание структуры, метода кодирования и процесса верификации поможет ответить быстро.


1. Базовый обзор

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Если разобрать, это три сегмента JSON в кодировке Base64URL:

  1. Header: Описывает алгоритм и тип, используемые токеном.
  2. Payload: Содержит информацию о пользователе и утверждения (claims).
  3. Signature: Подписан секретным ключом для гарантии целостности содержимого.

2. Header, Payload и Signature подробно

2.1 Header

{
"alg": "HS256",
"typ": "JWT"
}
  • alg: Алгоритм подписи, например HS256 (HMAC + SHA-256), RS256 (RSA + SHA-256).
  • typ: Тип токена, обычно JWT.

2.2 Payload

{
"sub": "1234567890",
"name": "Jane Doe",
"iat": 1516239022,
"exp": 1516242622,
"role": "admin"
}
  • Registered Claims (официально зарезервированные, но необязательные):
    • iss (Issuer): Субъект, выпустивший токен
    • sub (Subject): Субъект (обычно ID пользователя)
    • aud (Audience): Целевой получатель
    • exp (Expiration Time): Время истечения (Unix timestamp, в секундах)
    • nbf (Not Before): Токен недействителен до этого времени
    • iat (Issued At): Время выпуска токена
    • jti (JWT ID): Уникальный идентификатор токена
  • Public / Private Claims: Можно добавлять пользовательские поля (например, role, permissions), но следует избегать чрезмерного увеличения размера payload.

2.3 Signature

Процесс генерации подписи:

signature = HMACSHA256(
base64urlEncode(header) + "." + base64urlEncode(payload),
secret
)
  • Первые два сегмента подписываются секретным ключом (или закрытым ключом).
  • Когда сервер получает токен, он пересчитывает подпись. Если она совпадает, это подтверждает, что токен не был изменён и был выпущен легитимным источником.

Примечание: JWT гарантирует только целостность данных, но не конфиденциальность, если не применяется дополнительное шифрование.


3. Что такое кодировка Base64URL?

JWT использует Base64URL вместо Base64, со следующими отличиями:

  • + заменяется на -, а / заменяется на _.
  • Завершающие символы заполнения = удаляются.

Это гарантирует, что токен можно безопасно размещать в URL, Cookies или Headers без проблем, вызванных специальными символами.


4. Обзор процесса верификации

  1. Клиент включает Authorization: Bearer <JWT> в заголовок запроса.
  2. Сервер получает токен и:
    • Парсит Header и Payload.
    • Получает алгоритм, указанный в alg.
    • Пересчитывает подпись с использованием общего секрета или открытого ключа.
    • Сравнивает подписи и проверяет временные поля, такие как exp и nbf.
  3. Только после успешной верификации сервер может доверять содержимому Payload.

5. Шаблон ответа на собеседовании

«JWT состоит из трёх частей — Header, Payload и Signature — соединённых точкой .. Header описывает алгоритм и тип; Payload содержит информацию о пользователе и стандартные поля, такие как iss, sub и exp; Signature подписывает первые две части секретным ключом для проверки того, что содержимое не было изменено. Содержимое представляет собой JSON в кодировке Base64URL, но оно не зашифровано — только закодировано. Поэтому конфиденциальные данные не следует помещать в него напрямую. Когда сервер получает токен, он пересчитывает подпись для сравнения. Если подпись совпадает и токен не истёк, он считается валидным.»


6. Напоминания для дополнительных вопросов на собеседовании

  • Безопасность: Payload можно декодировать — никогда не помещайте в него пароли, номера кредитных карт или другую конфиденциальную информацию.
  • Истечение и обновление: Обычно используется в паре с краткоживущим Access Token + долгоживущим Refresh Token.
  • Алгоритмы подписи: Можно упомянуть разницу между симметричными (HMAC) и асимметричными (RSA, ECDSA) подходами.
  • Почему он не может быть бесконечно длинным?: Слишком большой токен увеличивает затраты на сетевую передачу и может быть отклонён браузером.

7. Ссылки