JWT-декодер

JSON Web Token — это три base64url-закодированных сегмента, соединённых точками: header.payload.signature. Header и payload — JSON; подпись — вывод HMAC или RSA/ECDSA по первым двум сегментам. Инструмент разбивает по точкам, base64url-декодирует каждую часть, парсит JSON и показывает стандартные временные claim вроде exp в виде человекочитаемых дат. Подпись он не проверяет — почему, смотрите в FAQ ниже.

Пример

Пример токена из спецификации JWT (HS256 подписан секретом your-256-bit-secret):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Декодированный header:

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

Декодированный payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Почему моя подпись JWT помечена как невалидная?

Этот декодер не проверяет подписи (см. FAQ), но если серверный верификатор отклоняет ваш токен, обычно виноваты следующие причины.

• Неверный секрет или ключ. Один символ разницы в HMAC-секрете даёт совершенно другую подпись. Убедитесь, что JWT_SECRET в env-переменной проверяющего сервиса совпадает с эмитентом.
• Несоответствие алгоритма. Токен, подписанный HS256, нельзя проверить RS256. Проверьте claim alg в header и настройте верификатор на тот же алгоритм.
• Истёкший токен. Даже корректно подписанный JWT не проходит валидацию, когда exp в прошлом. Сводка временных claim явно это покажет после декодирования.
• Расхождение часов. nbf (not-before) чуть в будущем плюс дрейф серверных часов дают ошибки «token not yet valid». Заложите небольшой допуск (например, 60 секунд) в верификаторе.
• Пробелы во вставленном токене. При копировании-вставке иногда попадает начальный пробел или концевой перенос. JWT должен быть ровно header.payload.signature без обрамляющих пробелов.
• alg: none. Если header говорит "alg": "none", токен не подписан. Отклоняйте такие в верификаторе — никогда не считайте их валидными.

Может ли инструмент проверить подпись JWT?

Нет, и это намеренно. Для проверки подписи нужен ключ подписи — общий секрет HMAC или асимметричный публичный ключ. Такой ключ принадлежит серверу, который выпускает или принимает токен, а не веб-странице. Инструмент только декодирует и показывает; верификация делается на сервере в вашем бэкенде.

Что внутри каждого из трёх сегментов JWT?

JWT — это header.payload.signature. Header — JSON с описанием алгоритма (alg) и типа токена. Payload — JSON с claim вроде sub, iat, exp. Подпись — base64url-закодированный вывод подписания первых двух сегментов секретом или приватным ключом. Первые два просто закодированы, не зашифрованы.

Мой JWT истёк — как это понять?

Посмотрите на claim exp в payload. Это Unix-таймштамп в секундах. Если Date.now() / 1000 больше exp, токен истёк. Инструмент отображает exp, iat и nbf как человекочитаемые даты под payload, чтобы вы могли понять с одного взгляда без ручных вычислений.

Что означает alg: none и почему это опасно?

alg: none — это возможность JWT, когда подпись пуста и не проверяется. Многие библиотеки исторически принимали такие токены, позволяя злоумышленникам подделывать JWT, формируя payload и ставя alg = none. Если вы видите это значение header, токен не подписан — не доверяйте серверу, который его принимает.

Сохраняете ли вы JWT, которые я сюда вставляю?

Нет. Мы не сохраняем ни одного токена, вставленного в декодер. Что бы вы ни бросили, оно удаляется при закрытии или обновлении вкладки — ничего не логируется, и у нас нет записи о токенах, которые вы изучали. И всё же: JWT даёт доступ до своего exp — относитесь к нему как к паролю и ротируйте любой продакшн-токен, который дебажите.

В секции подписи показан нечитаемый блоб — это нормально?

Да. Подпись — это бинарный вывод HMAC или RSA/ECDSA, закодированный в base64url. Он не предназначен для чтения человеком — только для криптографической проверки. Декодированные header и payload — это JSON-части, с которыми вы работаете. Пустая подпись означает, что токен не подписан (alg: none).