Описание инструмента
О Декодер и парсер JWT
Парсер JWT декодирует Header и Payload токена JSON Web Token, чтобы проверить alg, typ, состояние подписи и распространенные claims: iss, sub, aud, iat, nbf и exp.
Инструмент разбирает токены локально в браузере и может заново подписать отредактированные Header/Payload локальным секретом HMAC. Token не отправляется на wetool.site.
Как пользоваться Парсер JWT
- Вставьте полный JWT в формате header.payload.signature.
- Нажмите Decode, чтобы посмотреть Header, Payload и сводку основных claims.
- Проверьте exp, nbf и iat; обычно это секунды эпохи.
- Для тестовых токенов HMAC введите секрет, чтобы локально переподписать отредактированные Header/Payload.
Когда это полезно
- Отладить сеанс аутентификации и понять, токен истёк или еще ещё не действует.
- Проверить, что alg, typ, iss, aud и sub соответствуют API-шлюзу или контракту бэкенда.
- Отформатировать JSON полезной нагрузки и найти scope, role, tenant_id или другие поля приложения.
- Изменить claim в development токен и локально re-sign с известным секретом HMAC.
Структура JWT, claims и границы signature
JWT обычно состоит из трех Base64URL частей: Header, Payload и Подпись. Для декодирования Header/Payload секрет не нужен, но доверять токен можно только после проверки подписи правильным ключом.
- Header: обычно содержит alg и typ, описывая алгоритм подписи и тип токена.
- Payload: содержит claims вроде iss, sub, aud, iat, nbf, exp и поля конкретного приложения.
- Подпись: защищает Header/Payload от изменения; decode токен не доказывает, что подпись действительна.
- Временные claims: iat, nbf и exp обычно выражены в секундах Unix, а не в миллисекундах.
Частые вопросы: Парсер JWT
- Decode JWT это то же самое, что verify?
- Нет. Декодирование только читает Header и Payload. Для проверки необходимо сверить подпись с правильным секретом или открытым ключом.
- Почему payload виден без пароля?
- Header и Payload в JWT — это кодирование Base64URL, а не шифрование. Не храните секреты в обычной полезной нагрузке JWT.
- Что такое exp, iat и nbf?
- exp — время истечения, iat — время выпуска, nbf — время, с которого токен становится действительным. Обычно они записаны в секундах Unix.
- Token будет работать после изменения Payload?
- Обычно нет без новой подписи. Этот инструмент может локально переподписать тестовые токены HMAC при вводе секрета.
- JWT отправляется на сервер?
- Нет. Декодирование, редактирование и переподпись HMAC выполняются локально в браузере и не отправляются на wetool.site.
JWT и сессионные cookie
Session обычно хранит состояние на сервере и выдает браузеру идентификатор сеанса. JWT несет claims внутри токена, что удобно между сервисами, но требует внимательнее управлять expiration, ключами подписи и содержимым полезной нагрузки.
Проверка подписи JWT и чек-лист по alg
JWT, который можно декодировать, не становится автоматически заслуживающим доверия. Реальная проверка должна фиксировать алгоритм, источник ключа, issuer, audience и политику подписи.
- Не выбирайте алгоритм проверки только из заголовка alg токена; сервер должен использовать заранее заданный список разрешённых алгоритмов.
- alg=none, путаницу HS256/RS256 или значения kid, указывающие на внешние адреса, считайте конфигурацией с высоким риском.
- Этот инструмент полезен для просмотра и тестовых токенов HMAC, но проверка в рабочей среде должна выполняться на бэкенде или в шлюзе аутентификации.
Отладка времени exp, nbf и iat
Временные claims в JWT обычно указаны в секундах Unix. Если срок действия выглядит неверным, сначала проверьте путаницу секунд и миллисекунд, расхождение часов и отображаемый часовой пояс.
- Если exp раньше текущих секунд эпохи, токен истёк; если nbf позже текущего времени, токен ещё не действует.
- Если прочитать 13-значные миллисекунды как секунды, получится дата в далёком будущем; 10-значные секунды, прочитанные как миллисекунды, попадут около 1970 года.
- Серверы должны синхронизироваться по NTP и допускать небольшое расхождение часов, но длинные периоды отсрочки не должны скрывать ошибки конфигурации.