JWT Decoder — декодирование токена онлайн

Об инструменте

Декодируйте JWT локально в браузере: просматривайте Header и Payload, структуру Base64URL, алгоритм, стандартные claims, issuer, audience и даты iat, nbf и exp. Инструмент показывает диагностические предупреждения и экспортирует результат, но не объявляет подпись проверенной без доверенного ключа.

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

1. Вставьте JWT в компактном формате header.payload.signature.
2. Нажмите «Декодировать» — данные останутся в браузере.
3. Проверьте алгоритм, наличие подписи и состояние временных claims.
4. Сверьте issuer, audience, subject и остальные поля с документацией сервиса.
5. Скопируйте Header, Payload или весь отчёт; при необходимости скачайте JSON либо CSV claims.

Примеры

• alg: RS256: подпись создана RSA с SHA-256, но для проверки всё равно нужен публичный ключ.
• exp: время окончания действия в секундах Unix.
• aud: получатель, для которого предназначен токен; может быть строкой или массивом.
• alg: none: неподписанный токен, который нельзя принимать как доверенный.

JWT: структура токена, claims и безопасная проверка

JWT, или JSON Web Token, — компактный формат передачи набора claims между системами. Часто он используется в OAuth 2.0 и OpenID Connect, API, едином входе и межсервисном обмене. Декодирование помогает прочитать токен, но не подтверждает, что данные созданы доверенным издателем.

Из каких частей состоит JWT

Подписанный JWT в компактном представлении обычно является JWS и содержит три части через точку: Header, Payload и Signature. Первые две части содержат JSON, преобразованный в Base64URL. Третья часть хранит подпись. Изменение любого символа Header или Payload должно нарушить корректную криптографическую проверку.

Base64URL не шифрует содержимое

Header и Payload может прочитать любой, кто получил токен. Base64URL лишь заменяет бинарные байты печатными символами, удобными для URL и HTTP-заголовков. Поэтому в Payload нельзя помещать пароли, приватные ключи и сведения, которые должны оставаться секретными.

Header: alg, typ, kid и cty

alg сообщает заявленный алгоритм подписи, typ часто содержит JWT, kid помогает выбрать ключ, а cty описывает вложенный тип содержимого. Проверяющая сторона обязана сама ограничивать допустимые алгоритмы и безопасно сопоставлять kid с доверенным ключом, а не слепо выполнять указание токена.

Payload и стандартные claims

iss обозначает издателя, sub — субъект, aud — аудиторию, jti — идентификатор токена. Помимо зарегистрированных имён приложение может добавлять собственные claims, например роли или scope. Их смысл и допустимые значения определяются протоколом конкретного сервиса.

Как читать exp, nbf и iat

exp задаёт окончание действия, nbf — момент, раньше которого токен нельзя принимать, iat — время выпуска. JWT NumericDate хранится в секундах Unix, а не в миллисекундах. При проверке обычно допускают небольшое расхождение часов, но размер допуска должен быть ограничен политикой сервиса.

Issuer и Audience обязательны для контекста

Корректная подпись ещё не делает токен подходящим для любого API. Получатель сравнивает iss с ожидаемым издателем и убеждается, что его идентификатор присутствует в aud. Иначе действительный токен другого приложения или окружения может быть использован не по назначению.

Почему подпись нельзя проверить одним декодированием

Для криптографической проверки нужен секрет HS256 либо доверенный публичный ключ RSA, EC или EdDSA. Также требуется заранее разрешённый алгоритм и правила получения ключа, например проверенный JWKS издателя. Отображаемый сегмент подписи лишь доказывает, что строка содержит третью часть, но не её подлинность.

Опасность alg none и подмены алгоритма

alg: none обозначает неподписанный JWT. Защищённые системы не должны принимать его там, где ожидается подпись. Библиотека проверки должна фиксировать разрешённые алгоритмы и тип ключа, чтобы злоумышленник не смог заставить сервер применить другой способ проверки.

JWS и JWE

JWS обеспечивает подпись или MAC, но не скрывает Payload. JWE предназначен для шифрования и обычно содержит пять компактных сегментов. JWT Decoder разбирает трёхчастный JWS; для JWE нужен соответствующий ключ расшифрования и отдельная реализация.

Access token и ID token

ID token в OpenID Connect сообщает клиенту результат аутентификации и проверяется по правилам провайдера. Access token предназначен для API. Его формат не обязан быть JWT, а клиентское приложение не должно полагаться на внутренние claims непрозрачного токена без договора с издателем.

Отладка без ложного доверия

При диагностике сверяйте alg, kid, iss, aud, exp, nbf, scope и часовой пояс. Декодированный текст полезен для поиска неверной аудитории или истёкшего срока, но решение о доступе должен принимать сервер после полноценной проверки подписи и claims надёжной библиотекой.

Приватность локального декодирования

Ввод, Base64URL-декодирование, JSON-разбор и экспорт выполняются JavaScript-кодом в браузере. Токен не отправляется на сервер Terabita.by. Тем не менее рабочий access token остаётся секретом: не вставляйте его на общем устройстве, не публикуйте в снимках экрана и очищайте буфер обмена. Для просмотра JSON используйте JSON Formatter, для Base64URL — Base64, а для контрольных сумм — генератор хешей.