Кодировщик JWT
Собрать токен из claim’ов и по-настоящему подписать · работает в этой вкладке и никуда не отправляется
Заголовок
Полезная нагрузка
Ключ подписи
Ключ используется и отбрасывается — никогда не сохраняется в этом браузере и никуда не отправляется.
Ключ подписи выпускает токены, которые примут ваши системы. Для боевого ключа лучше своя среда.
HS256
Подписанный токен
Здесь появится подписанный токен. Для его создания ничего не отправляется: подпись вычисляет этот браузер.
Как работает Кодировщик JWT
Кодировщик JWT, который выпускает по-настоящему подписанный токен, а не base64-подделку. Напишите заголовок и полезную нагрузку в JSON, выберите алгоритм и вставьте общий секрет для HS или закрытый ключ PKCS#8 для RS, PS и ES — подпись вычисляет собственная WebCrypto вашего браузера. Срок действия, время выпуска и «не ранее» проставляются из пресетов, так что переводить эпоху вручную больше не придётся.
Напишите заголовок и полезную нагрузку в JSON, выберите алгоритм — и токен собирается и подписывается прямо по ходу набора. Пресеты срока действия проставляют iat, exp и при необходимости nbf из одного и того же мгновения, так что все три не разойдутся ни на секунду — а именно такие расхождения всплывают только внутри чужого допуска на расхождение часов.
alg всегда записывается из выбранного алгоритма, что бы ни стояло в вашем заголовке. Это не удобство: заголовок, объявляющий один алгоритм поверх подписи, сделанной другим, — отправная точка самой известной уязвимости JWT, и ни один законный токен из-за этого создать не запрещено. Любое другое поле заголовка сохраняется ровно так, как вы его написали.
HS-секреты короче хеша отклоняются по умолчанию — RFC 7518 требует 32 байта для HS256, 48 для HS384 и 64 для HS512, а браузер спокойно подпишет и четырьмя символами, хотя результат вскрывается офлайн за секунды. Проверку можно отключить: воспроизвести слабый токен иногда и есть задача.
Ключ подписи обрабатывается так же, как декодер обрабатывает свой ключ проверки, и даже осторожнее: он никогда не пишется в localStorage, не восстанавливается при перезагрузке, не попадает в события аналитики, и нет бэкенда, который мог бы его получить. Ключ подписи — самый опасный секрет в системе с JWT, поэтому для боевого ключа лучшей привычкой остаётся выпускать токены в собственной среде.
Частые вопросы
Безопасно ли вставлять сюда ключ подписи?
Ключ используется в вашей собственной вкладке и отбрасывается: он не пишется в хранилище, не попадает в события аналитики, и нет бэкенда, который мог бы его получить. При этом ключ подписи — самый опасный секрет в любой системе с JWT, потому что владеющий им может выпускать токены, которые примут ваши сервисы. Для боевого ключа лучшей привычкой остаётся выпуск токенов в собственной среде; этот инструмент рассчитан на разработку, тестирование и обучение.
Какими алгоритмами он умеет подписывать?
HS256, HS384 и HS512 с общим секретом, а также RS256/384/512, PS256/384/512 и ES256/384/512 с закрытым ключом в виде PEM-блока PKCS#8 или закрытого JWK. Он также создаёт незащищённый токен с `alg: none`, явно помеченный как ничего не доказывающий, — воспроизвести такой нужно, чтобы проверить, что ваш верификатор его отвергает.
Почему он отклоняет мой короткий секрет?
RFC 7518 требует ключ HMAC не короче хеша: 32 байта для HS256, 48 для HS384 и 64 для HS512. Браузеры спокойно подписывают секретом из четырёх символов, а полученный токен вскрывается офлайн за секунды. Кодировщик блокирует это по умолчанию и позволяет обойти запрет, ведь воспроизвести слабый токен иногда и есть задача.
Может ли он перезаписать алгоритм в моём заголовке?
Он всегда пишет `alg` из выбранного алгоритма, и это сделано намеренно. Заголовок, объявляющий один алгоритм поверх подписи, сделанной другим, — не токен, а отправная точка самой известной уязвимости JWT. Любое другое поле заголовка, которое вы напишете — `kid`, `cty`, произвольное — сохраняется ровно так, как введено.