Генератор JWT
Создание JSON Web Token с настраиваемым Header и Payload
Что такое JWT?
JWT Generator создает JSON Web Token из header, payload и параметров подписи. JWT состоит из трех частей в Base64URL и часто переносит claims между сервисами: ID пользователя, роли, время истечения, issuer и audience. Инструмент полезен для тестирования API, локальной разработки, обучения, отладки и быстрого создания примерных токенов. Но созданный токен заслуживает доверия только при правильном управлении ключами, выборе алгоритма, сроке действия и проверке на сервере. Секреты нельзя вставлять в публичные примеры, слабые алгоритмы и слишком долгий срок жизни опасны, а персональные или коммерчески чувствительные данные не должны находиться в незашифрованном payload.
Как использовать
Процесс генерации JWT
- Выберите алгоритм подписи (по умолчанию HS256)
- Введите или нажмите «Сгенерировать», чтобы создать секрет подписи
- Отредактируйте JSON полезной нагрузки и используйте кнопки быстрого добавления стандартных полей
- Установите время создания (iat) и истечения (exp)
- Нажмите кнопку «Сгенерировать JWT-токен»
- Скопируйте сгенерированный токен для тестирования или разработки
Безопасность токена
- Используйте надёжные секреты для алгоритмов HMAC и защищайте закрытые ключи для алгоритмов RSA/ECDSA.
- Задавайте реалистичные значения exp, iat, issuer и audience — синтаксически корректный JWT всё равно может быть небезопасным или отклонён вашим сервисом.
Применение
Технический принцип
Генератор и парсер JWT — обратные процессы: парсер разбирает три части, генератор их собирает. Ядро — вычисление сегмента Signature. Поток сборки: 1) Построить Header JSON, например {"alg":"HS256","typ":"JWT"}; 2) Построить Payload JSON со стандартными и приватными claim'ами; 3) Кодировать Header и Payload в Base64URL отдельно, получить h_b64 и p_b64; 4) Объединить h_b64 и p_b64 точкой: input = h_b64 + '.' + p_b64; 5) Вычислить подпись согласно alg: HMAC-SHA256/384/512(secret, input); 6) Кодировать результат подписи в Base64URL; 7) Итоговый токен = input + '.' + sig_b64. HMAC-SHA256: используем secret как ключ (рекомендуется ≥ 32 байт) и применяем HMAC к input. Внутри HMAC выполняет два раунда SHA-256: сначала из secret выводятся ipad/opad, затем считается SHA256(secret XOR ipad || msg) XOR opad. Сила ключа: длина secret напрямую определяет безопасность. RFC 7518 требует ключи HS256 ≥ 256 бит (32 байт). В продакшене всегда используйте криптографически безопасный ГСЧ (например, crypto.randomBytes); никогда не применяйте строки вроде 'secret', 'password' или '123456'. Частые ловушки: 1) Атака подмены alg: сервер обязан строго проверять alg и не должен читать alg из заголовка токена для диспетчеризации в соответствующий алгоритм; 2) Слабые ключи: слишком короткий secret подбирается перебором; 3) Подмена payload: HMAC гарантирует целостность — если злоумышленник изменит payload, серверная проверка провалится; 4) Утечка токена: JWT нельзя отозвать, поэтому после утечки остаётся только дождаться exp. Границы инструмента: создаются только HS256/HS384/HS512. Асимметричные алгоритмы вроде RS256 (RSA) и ES256 (ECDSA) требуют закрытого ключа на стороне эмитента и выпускаются серверным сервисом подписи или специализированным SDK, а не этой страницей.
- Ядро подписи HMAC-SHA256: HMAC(secret, header_b64 + '.' + payload_b64), выход — 256-битная подпись, кодируемая в Base64URL.
- Длина ключа HS256 должна быть >= 32 байт (256 бит); рекомендуется генерировать через crypto.getRandomValues или crypto.randomBytes — короткие ключи уязвимы к атакам по словарю.
- Этот инструмент создаёт только токены с HMAC-подписью (HS256/HS384/HS512). Асимметричные алгоритмы вроде RS256 или ES256 требуют закрытого ключа на стороне эмитента и здесь не выпускаются — для таких токенов используйте серверный сервис подписи или специализированный SDK.
- iat/exp/nbf — Unix-таймстампы в секундах (не миллисекундах); серверы обычно требуют exp > now(), nbf <= now() и iat <= now().
- Атака alg=none: поддерживайте серверный белый список допустимых алгоритмов (например, ['HS256']); никогда не выбирайте алгоритм динамически из заголовка токена. Многие JWT-библиотеки исторически допускали alg=none по умолчанию — это известная уязвимость.
- JWT нельзя отозвать после выпуска — единственный вариант дождаться exp. Для активного отзыва ведите чёрный список jti или используйте короткоживущий access token в паре с refresh token.
Примеры
Базовый пример HS256
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","name":"Alice","role":"admin","iat":1705312800,"exp":1705399200}
Secret: my-super-secret-key-32-bytes-long
Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwNTMxMjgwMCwiZXhwIjoxNzA1Mzk5MjAwfQ.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4UСвой срок действия через iat и exp
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"iss":"https://auth.example.com","sub":"user-456","aud":"api.example.com","iat":1705312800,"exp":1705316400}
Secret: another-strong-secret-32-bytes-long
Страница кодирует заголовок и полезную нагрузку в Base64URL, соединяет их точкой и применяет HMAC-SHA256 с общим секретом. В поле Token появляется готовая трёхсегментная строка, которую можно вставлять прямо в заголовок Authorization.Пользовательские claims
Header: {"alg":"HS256","typ":"JWT"}
Payload: {
"sub": "user-789",
"name": "Bob",
"role": "editor",
"tenant": "acme-corp",
"permissions": ["read:docs", "write:docs"],
"scope": "docs.read docs.write",
"iat": 1705312800,
"exp": 1705399200,
"jti": "550e8400-e29b-41d4-a716-446655440000"
}Часто задаваемые вопросы
JWT генерируется локально?
Да. Заголовок, payload и подпись вычисляются в вашем браузере с помощью Web Crypto API. Секрет подписи или приватный ключ никогда не покидает страницу. Сам токен следует считать данными, которые могут попасть в логи или быть раскрыты, особенно если вы вставите его в реальный сервис.
Какие алгоритмы подписи поддерживаются?
Этот инструмент создаёт HS256, HS384 и HS512 (HMAC с общим секретом). Асимметричные алгоритмы вроде RS256/RS384/RS512 (RSA) и ES256/ES384/ES512 (ECDSA) здесь не выпускаются — если проверяющая сторона их ожидает, используйте серверный сервис подписи или специализированный SDK. В проде избегайте alg=none: любой адекватный верификатор отклонит неподписанный токен.
Что входит в payload?
Стандартные claim-ы: sub, iss, aud, exp, iat, nbf плюс любые кастомные, которые использует ваш сервис. Держите payload компактным — JWT передаются в заголовках и растут с каждым запросом. Никогда не кладите внутрь пароли, полные номера карт и другие секреты; payload — это Base64URL, а не шифрование.
Как задать срок действия?
Установите exp в Unix-метку времени (в секундах, не в миллисекундах), после которой токен должен перестать быть валидным. Токены без exp технически допустимы, но большинство продакшен-сервисов настаивают на нём. Типичные значения — 5–60 минут для access-токенов, 7–30 дней для refresh-токенов.
Почему мой сгенерированный JWT не проходит проверку?
Типичные причины: alg в заголовке не совпадает с тем, что ожидает верификатор; secret/key отличается; claim-ы payload (iss, aud) не соответствуют конфигурации сервера; рассинхронизация часов между издателем и верификатором превышает допустимый зазор (обычно ±60 с); ручная правка сломала Base64URL-кодирование (не вставляйте переводы строк).
Отправляется ли мой секрет или приватный ключ на сервер?
Нет. Подписание целиком происходит в браузере через Web Crypto. Тем не менее, никогда не вставляйте продакшен-ключ подписи ни в какой веб-инструмент — тестируйте непродакшен-ключом, а затем подписывайте на реальном бэкенде.
Что выбрать — HS256 или RS256?
HS256 требует, чтобы обе стороны разделяли секрет, поэтому подходит только там, где один и тот же сервис и выпускает, и проверяет токен. RS256 (или ES256) позволяет издателю хранить приватный ключ, а каждому потребителю — проверять публичным — это правильный выбор для OAuth/OIDC и любой мультисервисной архитектуры. Этот инструмент создаёт только токены HS-семейства; для RS256/ES256 используйте серверный сервис подписи или специализированный SDK.