Декодер JWT

Что такое JWT?#

JWT (JSON Web Token, спецификация RFC 7519) — компактный, URL-безопасный токен, созданный для переноса утверждений (claims) между двумя сторонами. Это учётные данные, которые ваш браузер отправляет в API после входа, утверждение об идентичности, которое OAuth-провайдер передаёт доверяющему приложению, и конверт, в котором путешествуют большинство современных потоков сессий и контроля доступа. Прелесть в том, что утверждения — кто пользователь, что ему можно, когда истекает токен — едут внутри самого токена как JSON, поэтому принимающий сервис читает их без запроса к базе.

JWT состоит ровно из трёх частей в кодировке base64url, разделённых точками: header.payload.signature. Заголовок называет алгоритм и тип токена. Payload — это JSON-объект с утверждениями: зарегистрированными вроде sub (subject), iat (issued at), exp (expiration), nbf (not before), плюс любые собственные утверждения вашего приложения. Подпись — то, что эмитент вычислил по двум другим частям с помощью секрета или закрытого ключа; именно её проверка доказывает, что токен не подменён.

Эта страница декодирует и инспектирует JWT. Она разбивает три части, base64url-декодирует заголовок и payload в читаемый JSON, выводит стандартные временные утверждения как читаемые человеком даты и показывает живой значок статуса (Действителен, Истёк, Ещё не действителен). Она намеренно не проверяет подпись — для этого нужен секрет или открытый ключ эмитента, что выходит за рамки 100 % клиентского инструмента. Сегмент подписи показан как есть, в исходном виде.

Как пользоваться#

1. Вставьте токен в поле ввода слева. Это должны быть три разделённых точками сегмента; окружающие пробелы обрезаются автоматически.
2. Нажмите Пример, чтобы загрузить встроенный демонстрационный токен (с iat/exp/nbf), если вы просто хотите посмотреть, как устроен макет.
3. Нажмите Очистить, чтобы опустошить поле ввода и панели результата.
4. Читайте правую панель:
   • Значок статуса вверху — зелёный Действителен, Истёк или Ещё не действителен — на основе утверждений nbf и exp, сравнённых с текущим временем.
   • Карточка Заголовок (с алгоритмом в строке заголовка, например HS256).
   • Карточка Полезная нагрузка, аккуратно отформатированная как JSON.
   • Список временных утверждений — Выдан (iat), Не раньше (nbf), Истекает (exp) — каждое показано и как unix-временная метка, и как читаемая дата.
   • Сегмент Подпись в исходном виде, потому что это всё ещё байты в кодировке base64url.
5. Если токен неверно сформирован, красная строка состояния подскажет, что именно не прошло — проверку формы «три сегмента», base64url-декодирование или JSON-разбор.

Ключевые возможности#

• Живой статус временных утверждений. Читает iat, nbf и exp и сообщает, действителен ли токен сейчас, уже истёк или ещё не вступил в силу — три вопроса, которые вы реально задаёте при разборе бага со входом.
• Читаемые даты. Unix-числа вроде 1700000000 показаны рядом с UTC-датой, которую они обозначают, поэтому ментальная арифметика эпох больше не нужна.
• Алгоритм на виду. Значение alg из заголовка вынесено в строку заголовка карточки Заголовок, так что сразу видно, держите ли вы HS256, RS256 или что-то неожиданное.
• UTF-8-безопасное декодирование. Сегменты base64url декодируются в байты через TextDecoder, поэтому не-ASCII утверждения (имена, роли на других письменностях) отображаются корректно, а не как «кракозябры».
• Только декодирование — без проверки. Инструмент никогда не просит секрет, поэтому в нём безопасно вставлять токены, которым вы не вполне доверяете: ничего никуда не отправляется, а подпись показана, но не проверяется.

Разбор примера#

Нажмите Пример — и поле ввода заполнится токеном, заголовок которого декодируется в:

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

а payload — в:

{
  "sub": "1234567890",
  "name": "ArpGate Demo",
  "iat": 1700000000,
  "exp": 4102444800,
  "nbf": 1699999000
}

Список временных утверждений тогда покажет:

Issued at   1700000000  (2023-11-14 22:13:20 UTC)
Not before  1699999000  (2023-11-14 21:56:40 UTC)
Expires     4102444800  (2100-01-01 00:00:00 UTC)

Значок статуса — Действителен, потому что текущее время позже nbf и раньше exp. Сегмент подписи показан как буквальная строка c2FtcGxlLXNpZ25hdHVyZS1ub3QtdmVyaWZpZWQ — она декодируется в текст «sample-signature-not-verified», намеренный маркер того, что подпись этого токена иллюстративна, а не реальный вывод HMAC-SHA256.

Именно последний пункт — самое важное, что нужно понимать об этом инструменте: токен, который чисто декодируется, не обязательно достоверен. Любой может подделать заголовок и payload; только подпись, проверенная по секрету или открытому ключу эмитента, доказывает подлинность. Используйте эту страницу, чтобы читать утверждения и отлаживать временные окна; подписи проверяйте в реальном бэкенде.

FAQ#

Может ли этот инструмент сказать, достоверен ли JWT?#

Нет, и это по дизайну. Декодирование лишь читает JSON внутри токена — оно не доказывает, что токен выпущен тем, кем заявлено. Для проверки подлинности нужен соответствующий alg ключ (общий секрет для HS256, открытый ключ эмитента для RS256/ES256) и процедура верификации на доверенном бэкенде. Никогда не считайте чисто декодированный токен проверенным.

Статус показывает «Истёк». Можно ли обновить токен здесь?#

Нет. Обновление означает вызов refresh-endpoint’а вашего сервера аутентификации для получения нового access-токена — сетевая операция, которую эта статическая клиентская страница не может и не должна выполнять. Здесь можно лишь точно подтвердить, когда старый токен истёк, — обычно это и есть нужная зацепка.

В чём разница между iat, nbf и exp?#

iat (issued at) — когда токен создан, сугубо информативно. nbf (not before) — самое раннее время, когда токен следует принимать; до nbf валидирующий сервер должен его отклонять, даже если подпись верна. exp (expiration) — жёсткий предел, после которого токен обязан отбрасываться. У корректно сформированного токена nbf ≤ iat ≈ сейчас, а exp где-то в недалёком будущем (минуты для access-токенов, дольше для refresh-токенов).

В payload есть не-ASCII символы, и в других местах они отображаются криво. Почему здесь правильно?#

Потому что некоторые декодеры по ошибке трактуют каждый символ base64url как байт, вместо того чтобы сначала декодировать в сырые байты. Эта страница декодирует в Uint8Array, а затем пропускает через TextDecoder, который интерпретирует байты как корректный UTF-8. Это единственно правильный способ, и поэтому имена, роли и scopes на любой письменности отображаются как написано.