Декодер JWT (заголовок, полезная нагрузка, подпись, срок действия)

Вставьте JWT для мгновенного декодирования заголовка и полезной нагрузки в JSON. Распознаёт стандартные клеймы (iat, exp, nbf) и конвертирует Unix-метки времени в ISO 8601. Сигнализирует о просроченных или ещё невалидных токенах.

JWT-токен

Декодируется полностью в вашем браузере. Токен не передаётся по сети.

Заголовок

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

Полезная нагрузка

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "iat": 1730000000,
  "exp": 4886000000
}

Подпись присутствует: ✓
Выдан в (iat): 2024-10-27T03:33:20.000Z
Истекает в (exp): 2124-10-30T22:13:20.000Z

Как это работает

Как выглядит JWT

JWT — это три сегмента, закодированных в Base64url и разделённых точками: заголовок.полезная_нагрузка.подпись. Каждый сегмент — JSON-объект, закодированный для безопасной передачи в URL. Заголовок объявляет алгоритм подписи, полезная нагрузка содержит клеймы (субъект, срок действия, пользовательские данные), а подпись позволяет получателю проверить целостность при наличии ключа.

Этот декодер читает только первые два сегмента. Подпись — третий сегмент, но её проверка требует секретного/публичного ключа — это отдельная операция, которую мы здесь не выполняем.

Стандартные клеймы, которые нужно знать

iss (эмитент): кто создал токен. iat (выдан в): когда, в виде Unix-метки времени. exp (срок действия): когда перестаёт быть действительным, тоже Unix. nbf (не ранее): самое раннее время, когда его следует принять. sub (субъект): сущность, которую он представляет, часто ID пользователя. aud (аудитория): для кого предназначен токен, обычно URL сервиса.

Не все клеймы обязательны; минимальные JWT часто содержат только sub + iat + exp. Пользовательские клеймы — всё остальное — они находятся рядом со стандартными в полезной нагрузке.

Почему декодирование ≠ верификации

Любой может декодировать JWT — заголовок и полезная нагрузка — это просто Base64-закодированный JSON. Именно поэтому говорят «никогда не помещайте секреты в полезную нагрузку»: они фактически публичны.

Верификация означает проверку подписи по секретному ключу (HMAC) или публичному ключу (RSA/ECDSA). Без верификации нельзя доверять ни одному клейму в полезной нагрузке — злоумышленник может создать любую нагрузку.

Используйте этот инструмент для проверки токенов при отладке. Для верификации в продакшне используйте JWT-библиотеку на вашем сервере.

Частые вопросы

›Можно ли проверить подпись здесь?

Нет — верификация требует секретного или публичного ключа, который не должен покидать доверенную среду. Используйте серверную JWT-библиотеку (jsonwebtoken для Node, PyJWT для Python и т. д.).

›Токен покидает браузер?

Никогда. Декодирование выполняется локально; у нас нет серверного эндпоинта для его получения.

›Почему мой токен «невалидный»?

Часто: при копировании добавились/удалились пробелы, отсутствует один из трёх сегментов или один сегмент содержит неправильный Base64url. Обрежьте и попробуйте снова.

›В чём разница Base64url и Base64?

Base64url заменяет '+' на '-', '/' на '_' и убирает паддинг '=', чтобы закодированная строка была безопасна в URL и HTTP-заголовках. JWT всегда использует Base64url.

›Почему в моей Unicode-нагрузке искажённый текст?

Мы декодируем UTF-8, что является стандартом. Если нагрузка была закодирована иначе, JSON.parse может не сработать. Большинство эмитентов JWT корректно кодируют UTF-8.

›Безопасен ли HS256?

Если секрет достаточно длинный (≥256 бит) и держится в тайне — да. Распространённые уязвимости HS256: слабые секреты и принятие токенов с alg='none'. Используйте случайные секреты длиной ≥32 символа и явно отклоняйте 'none'.

›Почему предпочтительнее RS256 по сравнению с HS256?

RS256 (асимметричный RSA) позволяет публиковать открытый ключ для верификации, сохраняя закрытый ключ подписи в тайне. HS256 (симметричный HMAC) требует передачи секрета каждому верификатору. Для многосервисных архитектур RS256 безопаснее.

›Можно ли декодировать огромные токены?

Практический предел — ~10 МБ ввода; за этим пределом браузер может замедлиться. JWT обычно менее 4 КБ; если ваш больше, стоит задуматься, не слишком ли много данных в клеймах.