Създаване на подписан JSON Web Token (JWT)

Табло
Документация
API

генерира подписан JWT (HS256, HS384, HS512) от JSON payload и HMAC тайна, готов за вашите API тестове или токени за автентификация

Какво е JWT Builder?

JWT Builder е онлайн инструмент, който създава подписан JSON уеб токен (JWT) от JSON полезен товар и HMAC тайна. Насочен е към разработчици, които се нуждаят за бързо генериране на тестов токен за проверка на поведението на API, симулиране на сесия удостоверени в Postman или възпроизвеждат грешка, свързана с изтичането или обхвата на токен.

За разлика от нашия JWT декодер, който просто чете токен съществуващ, JWT Builder прави пълен токен: изгражда заглавката, кодира полезен товар, изчислява HMAC подписа и сглобява всичко в компактен формат header.payload.signature очаква се от всички JWT библиотеки на пазара.

Защо да генерирате JWT?

Създателят на JWT не е предназначен да издава производствени токени. Това е преди всичко инструмент за разработване и тестване. Ето най-често срещаните сценарии:

Интеграционни тестове: създаване на предвидими JWT за задвижване на E2E тестове които удрят защитени крайни точки, без да разчитат на реалния доставчик на самоличност.
API Mocks: Временно заменете повикване към IdP с подписан JWT локално със същата тестова тайна.
Локална разработка: свържете се със собствения си бекенд чрез ръчно генериране на a токен, съдържащ желаните претенции, без да се налага да преминавате през целия поток на OAuth2.
Демоверсии: илюстрирайте път за удостоверяване или работен процес въз основа на разрешения, без да имате реален IdP под ръка.
Възпроизвеждане на грешки: подправете токен с изтекъл срок на валидност, токен с Неправилен aud, токен без определени претенции, за тестване на пътищата за грешка на вашия API.
Отстраняване на грешки в персонализиран анализатор: инжектирайте JWT, специално конструирани за тествайте домашен анализатор.

Състав на JWT

Подписан JWT се състои от три сегмента, разделени с точка, всеки кодиран в Base64URL (вариант на Base64 без подложка и с -/_ в вместо +//):

Заглавка: JSON обект, който описва алгоритъма на подписа и типа на токена, например {"alg":"HS256","typ":"JWT"}. JWT Builder автоматично го генерира от на избрания от вас алгоритъм.
Полезен товар: произволен JSON обект, който съдържа претенциите на токена (тема, разрешения, дати на изтичане). Това е частта, която предоставяте.
Подпис: HMAC-SHA, изчислен при конкатенация base64url(header) + "." + base64url(payload) с вашия таен ключ. Тя е тази гарантира целостта на токена.

Случаи на използване в детайли

API макет за E2E тестване: вашият пакет Cypress или Playwright трябва да извика API което изисква Упълномощаване: Носител .... Вместо да организира пълно влизане в всеки тест подписваме JWT в движение със споделената тайна и я инжектираме в заглавката.
SSO Demo: представя обединено пътуване за удостоверяване без зависимост на онлайн IdP.
Test Fixture: генерира детерминистичен JWT от полезен товар, известен на служат като стабилно приспособление в тестовете на единици.
Диагностика на персонализиран анализатор: тестване на домашен JWT анализатор с токени умишлено минимални или умишлено странни (липсващи твърдения, неочаквани типове).
Обучение: разберете конкретно как е вграден JWT модифициране на полезния товар и наблюдаване на промяната на подписа.

Поддържани алгоритми: HS256, HS384, HS512

Нашият инструмент поддържа трите стандартни HMAC алгоритъма на JWT спецификацията (RFC 7519):

HS256: HMAC с SHA-256. 32 байта подпис. Най-използван в практиката, добър компромис между скорост и криптографска стабилност. Препоръчва се по подразбиране.
HS384: HMAC с SHA-384. 48-байтов подпис. Адаптиран към контексти, които изискват по-висок запас на безопасност.
HS512: HMAC с SHA-512. 64 байтов подпис. Най-здравият, на цената на малко по-голям жетон.

HMAC или RSA?

Алгоритмите HS* са симетрични: един и същ ключ се използва за подписване и проверка. Това е бързо и лесно, но означава, че всяка услуга, която може да провери токен, също е такава способни да ги излъчват. Ако трябва да разделите тези две роли (един емитент, множество потребители), обърнете се към алгоритмите RS256/RS384/RS512 (RSA, асиметричен), което можете да проверите с нашия JWT верификатор.

Сигурност: защита на вашата тайна

Сигурността на JWT, подписан в HMAC, разчита изцяло на поверителността на тайната. Някои основни правила:

Използвайте дълга, произволна тайна. RFC 7518 recommends at least the size от изхода на алгоритъма (32 байта за HS256, 48 за HS384, 64 за HS512). Парола човек като azerty123 е тривиално атакуван с груба сила офлайн.
Никога не подписвайте JWT от страна на клиента. Тайната ще бъде открита в кода JavaScript, разпространяван в браузъра, изложен на всеки потребител. Подписът винаги трябва да остане страна на сървъра.
Съхранявайте тайната в променлива на средата (напр. JWT_SECRET), никога в Git хранилище. Обмислете използването на трезор като HashiCorp Vault, AWS Secrets Manager или Symfony Secrets в зависимост от вашия стек.
Превръщайте тайната редовно (завъртане на ключове), особено след всеки инцидент или напускане на лице, което е имало достъп до конфигурацията.
JWT Builder е за тестване и обучение. За производство, използвайте JWT библиотеката на вашата рамка (lcobucci/jwt, firebase/php-jwt, jose-php).

Добри практики за искове

Полезният товар е безплатен JSON обект, но RFC 7519 дефинира набор от регистрирани искове които JWT библиотеките знаят как да интерпретират. Включването на правилните твърдения прави вашия токен преносим и избягва фини грешки:

iss (издател): идентификатор на емитента, например "https://api.example.com".
под (тема): идентификатор на съответното лице или образувание, често идентификационният номер потребител.
aud (аудитория): за кого е предназначен токенът, за да се предотврати повторната употреба на токен на друг API.
exp (време на изтичане): Unix клеймо за време, след което токенът вече не е валиден. Винаги включвайте, дори за тестов токен: токен без изтичане е a лош навик, който трудно се коригира след това.
nbf (не преди): клеймо за време, преди което токенът все още не е валиден. Полезно за предварително издаване на токен, който може да се активира по-късно.
iat (издадено на): време на издаване, полезно за регистриране и отмяна.
jti (JWT ID): уникален идентификатор на токена, важен за идемпотентност и прилагане на списък за отмяна.

Пример за типичен полезен товар

<пре>

{
  "iss": "https://api.example.com",
  "под": "потребител-12345",
  "aud": "мобилно приложение",
  "iat": 1714723200,
  "exp": 1714726800,
  "jti": "9f2d6b1e-2c4a-4f8a-9c3a-87a2b8a4b7e1",
  "обхват": "четене:профил запис:профил"
}

Как да използвате инструмента

Въведете полезния товар като валиден JSON. Това е обект, така че започва с { и завършва с }.
Посочете тайната на HMAC. Изберете дълъг произволен низ за производствени токени.
Изберете алгоритъма: HS256 по подразбиране, HS384 или HS512 според вашите нужди.
Щракнете върху създаване. Подписаният JWT се появява, готов за поставяне в заглавка Упълномощаване: Носител ....
След това можете да проверите токена със същата тайна на потвърдете последователността на двупосочното пътуване или декодирайте за препрочитане неговото съдържание.

Често задавани въпроси

Кой алгоритъм да избера: HS256, HS384, HS512?

За почти всички случаи, HS256 е правилният избор. Предлага ниво на напълно достатъчна сигурност за токени за удостоверяване, с компактен подпис (32 байта) и бързо изчисление. HS384 и HS512 са оправдани само в контексти точни регулаторни изисквания или ако управлявате токени с много дълъг живот. Размерът на По-високият подпис прави всяка HTTP заявка по-тежка.

Как да генерирам RSA двойка, за да подпиша моите JWT?

С OpenSSL в две команди: openssl genrsa -out private.pem 2048 за ключа private, след това openssl rsa -in private.pem -pubout -out public.pem за извличане публичния ключ. За нови услуги вече препоръчваме ключове за сигурност. 3072 бита или 4096 бита. Частният ключ остава от страната на подателя; публичният ключ е свободно се разпространява до услуги, които трябва да проверяват токени.

Какъв е препоръчителният срок на годност?

За токен за достъп: 5 до 15 минути. За маркер за опресняване: няколко дни няколко седмици, но с механизъм за анулиране от страната на сървъра. Колкото повече е токенът дълъг живот, толкова по-голям е работният прозорец в случай на теч. За тестови JWT, вие може да отнеме по-голяма продължителност, но избягвайте exp за няколко години: те в крайна сметка изтичат в хранилищата на Git.

Мога ли да подпиша с много кратък таен ключ?

Технически да, но силно не се препоръчва. HMAC тайна на по-малко от 16 байта е слабо устойчив на офлайн груби атаки и се намира в естеството на инструментите, които разбиват JWT HS256 с ниска секретност за секунди. The RFC 7518 препоръчва поне размера на изхода на алгоритъма: 32 байта за HS256, 48 за HS384, 64 за HS512. Генерирайте своите тайни с openssl rand -base64 64.

Защо полезният ми товар е отхвърлен?

Полезният товар трябва да е валиден JSON обект. Често срещани грешки: единични кавички вместо удвоява, допълнителна запетая преди }, стойност без кавички за низ. Валидирайте първо вашия JSON с нашия JSON формат.

Може ли генерираният JWT да бъде дешифриран от някой друг?

Подписаният JWT не е криптиран: полезният товар е просто кодиран с Base64URL. Всичко светът може да го прочете. Ако полезният товар съдържа чувствителни данни, използвайте JWE формата (JSON Web Encryption), което добавя криптиране. Нашият инструмент създава JWS (само подписан).

Пример за заявка

curl -X POST https://cdrn.fr/api/v1/tools/jwt-builder/execute \
  -H "Content-Type: application/json" \
  -d '{"payload":"...","secret":"...","algorithm":"HS256"}'

Входна схема

Поле	Тип	Задължително	По подразбиране
`payload`	text	✓	–
`secret`	text	✓	–
`algorithm`	choice (HS256, HS384, HS512)	✓	`HS256`

Крайни точки

GET https://cdrn.fr/api/v1/tools - изброява всички достъпни инструменти
GET https://cdrn.fr/api/v1/tools/jwt-builder - извлича схемата на този инструмент
POST https://cdrn.fr/api/v1/tools/jwt-builder/execute - изпълнява този инструмент с JSON payload