Генератор JWT

Соберите JWT с sub, name, iat, exp и своими claims и подпишите по HS256 через Web Crypto в браузере. Токен из трёх частей и проверка в декодере.

Всё работает в вашем браузере — данные не отправляются на сервер.

Зачем генерировать JWT вручную

Генератор JWT нужен тогда, когда надо быстро получить настоящий подписанный токен для тестов: проверить, как фронтенд разбирает exp, подсунуть тестовой авторизации свой sub и role, разобрать на практике, из чего состоит JSON Web Token. Токен собирается по RFC 7519: заголовок и полезная нагрузка кодируются в base64url, к ним применяется подпись HMAC-SHA-256 по вашему секрету, и три части склеиваются точками. Всё считается в браузере через Web Crypto, без серверной части. Для учёбы это самый короткий путь: вы меняете один claim — и сразу видите, как меняется подпись.

Что умеет генератор

Собирает payload из полей sub, name, iat и exp с автозаполнением дат в секундах Unix
Принимает произвольные claims вида ключ–значение, числа остаются числами
Подписывает токен алгоритмом HS256 через Web Crypto, без внешних библиотек
Показывает готовый токен и каждую из трёх частей отдельно, с копированием в один клик
Прячет секрет под маской и предупреждает, что браузерная подпись годится только для тестов

Как получить токен

Заполните sub, name и даты: кнопки подставят iat со временем сейчас и exp на час вперёд
Добавьте свои claims при необходимости, например role или user_id
Введите секретный ключ и нажмите «Подписать токен»
Скопируйте готовую строку из трёх частей и проверьте её в декодере

Как строится подпись

Токен состоит из трёх частей, разделённых точками. Первая часть — заголовок, для HS256 это фиксированный JSON с полями alg и typ, и в base64url он всегда выглядит одинаково. Вторая — payload, то есть ваш набор claims в формате JSON. Каждая часть кодируется в base64url: вариант base64, где плюс заменён на дефис, слэш на подчёркивание, а паддинг убран, чтобы токен спокойно жил в заголовке Authorization. Третья часть — подпись: над строкой «первая часть.вторая часть» считается HMAC-SHA-256 с вашим секретом. Ключ импортируется через crypto.subtle.importKey, подпись снимается crypto.subtle.sign, и всё это происходит в вашем браузере.

Claims, которые чаще всего попадают в payload

Claim	Пример значения	Что означает
sub	"user-42"	идентификатор субъекта, о ком этот токен
name	"Иван"	человеческое имя, публичный claim без специального смысла
iat	1735689600	issued at: момент выпуска в секундах Unix
exp	1735693200	expiration: после этого момента токен недействителен
iss	"auth.example.com"	кто выпустил токен
aud	"api.example.com"	для какой аудитории предназначен
role	"admin"	произвольный claim приложения, сервер трактует сам
jti	"a1b2c3"	уникальный идентификатор токена, полезен для отзыва
nbf	1735689600	not before: токен недействителен раньше этого момента
email	"ivan@example.com"	тоже публичный claim, читается всеми без секрета

Первые шесть claims из списка — зарегистрированные в RFC 7519, остальные встречаются как публичные или приватные соглашения между вашими сервисами.

Где подписанный токен нужен прямо сейчас

Тестирование авторизации — первая сцена. Фронтенд-разработчик проверяет, как приложение ведёт себя при истёкшем exp: ставишь exp на минуту вперёд, ждёшь, смотришь, появился ли экран повторного входа. Бэкенд-разработчик принимает токен от фронтенда и хочет удостовериться, что middleware правильно отклоняет токен с подделанной подписью: генерируешь корректный токен, потом меняешь в нём букву, и оба случая разложены по полочкам. QA готовит набор фикстур: валидный токен, просроченный, токен без роли, токен с чужим sub — всё это занимает минуты.

Вторая сцена — учёба и разбор. На настоящем примере видно, как payload превращается в строку, как меняется подпись от изменения одного символа, почему сервер не примет токен с правленным claim. Студент или джун, собравший токен руками, больше не путает подпись с шифрованием и понимает, почему пароль никогда не кладут в payload. Полное устройство формата с картинкой-схемой разобрано в статье JWT: что внутри токена — она хорошо дополняет практику на этом генераторе.

Фикстуры для автотестов: валидный, просроченный и подделанный токены
Проверка обработки exp на фронтенде и middleware на бэкенде
Отладка роли и sub в авторизации без запуска сервера аутентификации
Учебные задания по формату JWT и подписи HMAC
Демо и документация: показать команде настоящий токен, а не мок

Типичные ошибки при генерации токенов

Первая ошибка — использовать настоящий продакшен-секрет в браузерной форме. Даже если страница не отправляет данные по сети, секрет остаётся в истории ввода браузера и в памяти расширений, а привычка вводить его в сторонние формы опасна сама по себе. Для генератора годится тестовый секрет вроде строки из двенадцати случайных символов, а настоящие ключи держат на сервере и на генератор не тратят.

Вторая ошибка — перепутать секунды и миллисекунды в iat и exp. Стандарт требует секунды; если передать миллисекунды, число окажется в далёком будущем, и токен с формально правильным exp будет жить несколько столетий. Третья — забыть, что payload читается всеми: пароли, номера карт и персональные данные туда не кладут, даже если токен подписан. И четвёртая — считать, что подпись HS256 защищает содержимое от чтения: она защищает только от изменения.

Настоящий секрет не вводят в браузерные генераторы, только тестовый
iat и exp в секундах Unix, без миллисекунд
Payload не шифруется: секретных данных в нём быть не должно
Подпись гарантирует неизменность, но не тайну содержимого
Слишком долгий exp делает отзыв доступа невозможным
Изменённый даже на один символ payload меняет всю подпись

Разбор примера: токен на трёх частях

Возьмём минимальный payload: sub равен user-1, name равен Иван, iat и exp заполнены кнопками. Заголовок HS256 фиксирован, поэтому его base64url всегда одинаковый. Payload после упаковки получится длиной около сотни символов — кириллица в JSON уходит в UTF-8, поэтому Иван занимает больше байтов, чем латиница. Подпись считается над строкой «заголовок.payload» с вашим секретом и превращается в 43 символа base64url. Склеенные точками части и есть готовый токен длиной в пару сотен символов, который удобно копировать целиком.

Дальше полезно посмотреть на токен глазами декодера: он покажет те же самые claims и подпись отдельно. Если поменять в payload одну букву и переподписать — подпись изменится вся, потому что HMAC размазывает изменение по всем 32 байтам. Если поменять букву и НЕ переподписать — сервер отклонит токен на проверке подписи. В таблице ниже — что куда входит.

Из чего складывается готовый токен

Часть	Что содержит	Как получается
header	alg HS256 и typ JWT	фиксированный JSON в base64url, выглядит как eyJhbGciOiJI...
payload	ваши claims: sub, name, iat, exp и свои	JSON кодируется в base64url
signature	32 байта двоичных данных	HMAC-SHA-256 над header.payload с секретом
разделитель	точка между частями	части склеиваются в одну строку
кодирование	base64url вместо base64	плюс меняется на дефис, слэш на подчёркивание
длина	около 200 символов для такого payload	зависит от числа и размера claims
передача	заголовок Authorization	Bearer и токен без переносов строк
проверка	сервер пересчитывает подпись	совпала — токен подлинный, не совпала — отклонён

Ни одна из трёх частей не содержит секрета: секрет нужен только в момент подписи и в момент проверки, в сам токен он не попадает.

Что почитать и чем дополнить генератор

Генератор и декодер образуют пару: один собирает токен, другой разбирает. После того как токен готов, загляните в декодер JWT и сверьте claims. Чтобы понять, какая математика стоит за подписью, откройте генератор HMAC — там видно, как сообщение и ключ превращаются в 32 байта подписи, и есть проверочные векторы. Секреты для настоящих систем делают случайными строками: для этого подходит генератор паролей, а требования к длине и энтропии разобраны в статье о надёжном пароле.

Для глубокого погружения в формат остаётся текст стандарта: RFC 7519 описывает JWT, а RFC 7515 — способ подписи JWS, который здесь и используется. В учебных материалах сайта формат разобран по частям в статье JWT: что внутри токена, а упаковка base64url — в разборе Base64 простыми словами. Связка этих четырёх текстов покрывает и практику, и теорию: собрал, разобрал, понял подпись, понял упаковку.

Генератор и декодер дополняют друг друга: собрал — проверь
HMAC-генератор показывает математику подписи на проверяемых векторах
Настоящие секреты генерируют случайными строками и хранят на сервере
RFC 7519 описывает claims, RFC 7515 — саму подпись
Для нескольких сервисов с разными ключами смотрят в сторону RS256

Частые вопросы

Из чего состоит JWT

Из трёх частей, разделённых точками: header.payload.signature. Заголовок описывает алгоритм подписи, для этого генератора это {"alg":"HS256","typ":"JWT"}. Полезная нагрузка содержит claims — утверждения о пользователе и о самом токене: sub для идентификатора субъекта, iat для момента выпуска, exp для момента истечения. Подпись гарантирует, что ни заголовок, ни payload не изменились после выпуска. Все две первые части — просто закодированный JSON, их читает любой декодер, поэтому секретные данные в JWT класть нельзя.

Почему токен подписан, но не зашифрован

Подпись и шифрование решают разные задачи. Подпись HS256 гарантирует целостность: изменить хоть один символ payload без знания секрета не выйдет, сервер отклонит токен. Но читать payload может любой желающий: base64url — это не шифр, а упаковка, она разворачивается в одну строку кода. Поэтому правило такое: в JWT кладут идентификатор пользователя, роль, время жизни — то, что не страшно показать, но опасно подменить. Для настоящей тайны нужен либо JWE, либо обычное шифрование поверх, и генератор здесь честно подписывает, но не прячет содержимое.

Что такое iat и exp и в каком они формате

Это зарегистрированные claims для времени, и оба хранятся в секундах Unix-времени, без миллисекунд. iat, issued at, отмечает момент выпуска токена; exp, expiration time, — момент, после которого токен считается недействительным, и сервер обязан его отклонить. Если поставить exp на год вперёд, вы получите долгоживущий токен, что неудобно для отзыва доступа, поэтому на практике ставят от нескольких минут до нескольких часов. Перевод дат туда-обратно удобно делать через конвертер Unix-времени, а общая теория разобрана в статье про Unix-время.

Что делает алгоритм HS256

HS256 означает HMAC с хеш-функцией SHA-256: подпись строится на секретном ключе, который знают и тот, кто выпускает токен, и тот, кто проверяет. Один и тот же секрет и подписывает, и проверяет, поэтому алгоритм называют симметричным. Подпись занимает 32 байта и в токене выглядит как 43 символа base64url. Если секрет короткий или словарный, перебор становится реальным, поэтому для настоящих систем ключ делают длинной случайной строкой — сгенерировать его можно генератором паролей, а сам механизм подписи разобран в генераторе HMAC.

Чем HS256 отличается от RS256

Количеством ключей. В HS256 один общий секрет: им и подписывают, и проверяют, поэтому проверяющая сторона технически может выпускать токены сама. В RS256 пара ключей: приватным подписывают, публичным проверяют, и публичный ключ можно раздавать хоть всем сервисам — подделать подпись по нему нельзя. Правило выбора простое: один сервис, который и выпускает, и проверяет токены, спокойно живёт с HS256; несколько сервисов, где подписывает только авторизация, требуют RS256. Наш генератор покрывает HS256 — он самый частый в учебных примерах и в небольших приложениях.

Можно ли доверять токену, сгенерированному в браузере

Как учебному материалу — да, как элементу продакшена — нет. Подпись математически корректна: сервер с тем же секретом примет такой токен. Проблема в обращении с секретом: строка, введённая в браузерную форму, прошла через чужой компьютер, историю ввода и расширения, и считать её надёжной нельзя. В настоящем приложении секрет живёт в переменных окружения сервера, подпись делает бэкенд, а фронтенд получает готовый токен из ответа API. Генератор специально показывает красное предупреждение, чтобы привычка «введу настоящий секрет сюда» не закрепилась.

Как проверить токен, который я здесь получил

Вставьте его в декодер JWT — он развернёт header и payload в читаемый JSON и покажет подпись отдельно. Так вы убедитесь, что claims легли как задумано, а даты превратились в правильные секунды. Полную проверку подписи декодер в браузере для HS256 не делает, потому что для этого нужен секрет, — это и есть граница между разбором токена и его верификацией. Если хотите почувствовать, как подпись реагирует на изменения, добавьте в payload лишнюю букву и сравните подписи: они изменятся полностью.

Зачем нужен base64url вместо обычного base64

Знаки плюс и слэш, которые использует обычный base64, плохо переносятся в URL и в заголовках HTTP: плюс в адресной строке означает пробел, а слэш режет путь. Поэтому в JWT применяется вариант base64url: плюс заменён дефисом, слэш — подчёркиванием, а символы паддинга убраны за ненадобностью. Благодаря этому токен передаётся в адресе возврата, в cookie и в заголовке Authorization Bearer без всяких дополнительных замен. Как устроена сама упаковка байтов в символы, подробнее написано в разборе Base64 простыми словами.

Полезные статьи

HMAC-подпись API-запроса: зачем она и как её считать

Зачем подписывать API-запросы и вебхуки, как устроен HMAC простыми словами, почему подпись не шифрование, безопасное сравнение подписей, JWT HS256 и пошаговый расчёт HMAC-SHA-256 с проверенным примером.

HS256 и RS256: какую подпись JWT выбрать

Чем HS256 отличается от RS256, кому хватает одного секрета, когда нужна пара ключей RSA, размеры подписей и скорость, атака alg confusion и фиксация алгоритма, проверка токена обоими способами на реальном примере.