Инструмент анализа JWT
Декодирование и проверка JSON Web Token, просмотр Header, Payload и Signature
Примеры JWT
Что такое JWT?
JWT (JSON Web Token) — это открытый стандарт (RFC 7519) для безопасной передачи информации между сторонами. JWT состоит из трёх частей, разделённых точками: Header содержит тип токена и алгоритм подписи, Payload содержит данные claims, а Signature используется для проверки целостности токена. JWT широко используется для аутентификации и обмена информацией. При работе с JWT важно различать decoding и verification. Header и payload только Base64URL-кодированы, поэтому их можно прочитать даже при недействительной подписи. Доверие появляется только после server-side проверки подписи, алгоритма, срока, issuer и audience. Чувствительные данные нельзя помещать в незашифрованный payload, потому что любой обладатель токена может их прочитать. Отладка токена полезна, но это не то же самое, что принятие токена.
Как использовать
Как использовать
- Вставьте JWT в поле ввода — инструмент автоматически распарсит и отобразит содержимое заголовка и полезной нагрузки
- Нажмите на цветные теги, чтобы скопировать соответствующую часть в кодировке Base64
- Введите секрет в области проверки подписи, чтобы убедиться в корректности подписи (поддерживаются алгоритмы HS256/HS384/HS512)
- В области ключевой информации отображаются декодированные значения стандартных полей, статус истечения выделен цветом
Советы по безопасности
- Этот инструмент работает локально в вашем браузере, токен никогда не отправляется на сервер
- JWT только кодирует и подписывает данные, но не шифрует их — любой может декодировать и просмотреть содержимое
- Не храните конфиденциальную информацию в JWT (например, пароли, номера кредитных карт и т. д.)
- Всегда используйте HTTPS для передачи JWT в рабочей среде
Применение
Технический принцип
JWT (JSON Web Token, RFC 7519) состоит из трёх частей — Header.Payload.Signature — соединённых точкой. Header: описывает тип токена и алгоритм подписи, например {"alg":"HS256","typ":"JWT"}. alg определяет способ вычисления Signature; распространённые варианты — HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA-SHA256) и none (без подписи — запрещено в продакшене). Payload: также называется claims — набор JSON-полей. RFC 7519 определяет 7 стандартных зарегистрированных полей: iss (издатель), sub (субъект, обычно ID пользователя), aud (аудитория), exp (истечение), nbf (не раньше), iat (время выдачи) и jti (уникальный ID). Разработчики могут добавлять любые пользовательские поля, например userId, role, tenant. Signature: Header и Payload кодируются в Base64URL, соединяются точкой, затем подписываются алгоритмом, указанным в alg, с использованием ключа. HS256 использует HMAC-SHA256(secret, header_b64 + '.' + payload_b64); RS256 использует приватный ключ RSA. Получатель пересчитывает подпись тем же способом и проверяет совпадение. Base64URL и стандартный Base64: '+' заменяется на '-', '/' заменяется на '_', отбрасывается завершающее заполнение '=', поэтому результат можно помещать в URL-пути и строки запроса без процентного кодирования. Base64URL — это только кодирование, оно не обеспечивает шифрования или безопасности, и любой может декодировать и прочитать полезную нагрузку. Граница безопасности: JWT гарантирует только «не подделан», но не «содержимое конфиденциально». Распространённая ошибка — помещать в payload номера телефонов, паспортные данные или хеши паролей, которые видны всем.
- Трёхчастная структура: Header.Payload.Signature, каждая часть кодируется в Base64URL; подпись — HMAC(secret, header_b64 + '.' + payload_b64) или RSA(privateKey, тот же вход).
- Base64URL заменяет '+' → '-', '/' → '_' и отбрасывает завершающее заполнение '=', поэтому закодированный результат можно напрямую использовать в URL (без процентного кодирования).
- Этот инструмент локально проверяет только подписи семейства HMAC (HS256/HS384/HS512). Асимметричные алгоритмы вроде RS256 или ES256 требуют открытого ключа из JWKS-эндпоинта эмитента, поэтому проверка подписи должна выполняться на сервере, владеющем открытым ключом — страница может декодировать заголовок и полезную нагрузку, но не способна их верифицировать.
- Стандартные поля: iss (издатель), sub (субъект), aud (аудитория), exp (Unix-таймстамп истечения в секундах), nbf (не раньше), iat (время выдачи), jti (JWT ID, защита от повторного использования).
- Атака alg=none: поле alg должно строго валидироваться, алгоритм none должен отклоняться, иначе злоумышленник может подделать любой токен; также необходимо предотвращать атаки подмены алгоритма (проверка HS256-токена с использованием публичного ключа в качестве секрета).
- JWT не шифруется: payload — это открытый Base64URL, а не зашифрованные данные; для конфиденциального содержимого используйте JWE (JSON Web Encryption), но на практике распространённый подход — хранить чувствительные данные на бэкенде и ссылаться на них через поле sub.
Примеры
Стандартный токен HS256
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzA1MzEyODAwLCJleHAiOjE3MDUzMTY0MDB9.znHapMygT8K8YZN4K8zM1sV3bKlQ5pY3xE2gR4wN1vM
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"1234567890","name":"Jane Doe","iat":1705312800,"exp":1705316400}
RFC: RFC 7519 раздел 3 определяет Registered Claim Names (sub, iat, exp)Истёкший токен
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsImV4cCI6MTYwMDAwMDAwMH0.OxQ0fUKW0z4mK0xJ4vF0uF7eZB9wK3yF8pL2nQ6tX1k
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","exp":1600000000}
Status: истёк (exp < now)
Примечание: claim exp использует NumericDate (секунды с Unix-эпохи согласно RFC 7519 раздел 2)Токен с пользовательскими claims
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQ1NiIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsInRlbmFudCI6ImFjbWUiLCJpYXQiOjE3MDUzMTI4MDAsImV4cCI6MTcwNTMxNjQwMCwiYXVkIjoiYXBpLmV4YW1wbGUuY29tIn0.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4U
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-456","name":"Alice","role":"admin","tenant":"acme","iat":1705312800,"exp":1705316400,"aud":"api.example.com"}
Примечание: role, tenant - приватные claims, не определены в RFC 7519Чек-лист безопасности при реализации JWT
1. Никогда не храните секреты в payload - JWT кодируется, а не шифруется
2. Используйте надёжные секреты для HS256 (>= 256 бит / 32 случайных символа)
3. Предпочитайте RS256/ES256 для проверки открытым ключом в мульти-сервисных системах
4. Проверяйте заголовок alg - отклоняйте 'none' или неожиданные алгоритмы
5. Проверяйте метки времени exp, nbf, iat, прежде чем доверять токену
6. Сверяйте aud со своим сервисом, чтобы предотвратить переиспользование токена в других приложениях
7. Храните в HttpOnly cookies, а не в localStorage (защита от XSS)
RFC: RFC 8725 (JWT Best Practices) описывает эти аспекты безопасностиЧасто задаваемые вопросы
Из каких трёх частей состоит JWT?
Заголовок, payload и подпись, разделённые точками. Заголовок объявляет алгоритм подписи и тип токена. Payload несёт claim-ы: sub, iss, aud, iat, exp и любые пользовательские данные. Подпись позволяет верификатору убедиться, что токен не был подделан. Заголовок и payload — это JSON в Base64URL: они подписаны, но не зашифрованы.
Зашифрован ли JWT?
Нет — обычный JWT в формате JWS подписан, но не зашифрован. Любой, кто перехватит его, может Base64URL-декодировать заголовок и payload и прочитать каждый claim, включая ID пользователей, email-ы и роли. Считайте содержимое JWT публичной информацией; никогда не кладите пароли или секреты в payload. JWE (зашифрованный JWT) существует, но используется намного реже.
Что означает каждый стандартный claim?
iss — издатель; sub — субъект (часто ID пользователя); aud — аудитория (предполагаемый получатель); exp — срок действия (Unix-секунды); nbf — не ранее; iat — выпущен в; jti — уникальный ID токена для отзыва. Они определены в RFC 7519. Кастомные claim-ы можно добавлять свободно — ставьте префикс для специфичных вендорам, чтобы избежать коллизий.
Как проверить JWT?
Прочитайте заголовок alg, возьмите соответствующий ключ (HS256 — общий секрет, RS256/ES256 — публичный ключ из JWKS-эндпоинта издателя), пересчитайте подпись над закодированным header.payload и сравните. Затем проверьте exp, nbf, iss и aud. Отвергайте токен, если alg равен none или отличается от того, что ожидает ваш сервер. Этот инструмент локально проверяет только подписи HS256/HS384/HS512 (общий секрет); проверка RS256/ES256 должна выполняться на сервере, владеющем открытым ключом.
Проверка происходит в моём браузере?
Да. Страница парсит JWT локально и проверяет подписи HS256/HS384/HS512 с помощью HMAC, выполняемого в JavaScript в твоём браузере. Токен не попадает на наш сервер, но помни: JWT по своей сути передаётся в URL и заголовках — считай, что любой скопированный JWT может оказаться в логах.
Чем опасен alg=none?
RFC 7519 разрешает alg=none для неподписанных токенов. Уязвимый верификатор может принять такой токен, хотя у него нет подписи, что позволит атакующему подделать любой payload. Современные библиотеки по умолчанию отвергают alg=none; если пишете верификатор сами, жёстко закодируйте ожидаемый алгоритм, а не доверяйте заголовку.
Насколько большим может быть JWT?
Протокольного лимита нет, но JWT обычно оказываются в HTTP-заголовках (Authorization: Bearer ...), а многие серверы ограничивают заголовки примерно 8 КБ. Набивая JWT claim-ами, вы утяжеляете каждый запрос. Если нужно много состояния сессии, используйте серверную сессию и кладите в JWT небольшой ссылочный токен.