В первый раз, когда мне пришлось отладить сломанный поток аутентификации на Laravel API, я потратил день впустую, потому что не смог произвести токен, которому доверял Промежуточное ПО продолжало возвращать 401, и я не мог сказать, была ли ошибка в моем проверочном коде или в токене, которым я его кормил. Мне нужен был известный-хороший JWT с конкретным sub, конкретное истечение срока действия, и секрет, который я контролировал, так что я мог изолировать одну сторону проблемы Копирование случайного токена из ответа Stack Overflow сделало противоположное помощи, потому что он был подписан с секретом, которого у меня не было.
Это пробел, заполняет генератор JWT. Это не служба подписи производства. Это настольный инструмент на момент, когда вы создаете или тестируете что-то, что потребляет веб-токены JSON, и вам нужен действительный по требованию, с точными утверждениями и точным секретом, который вы выбираете. Это руководство охватывает, как работает инструмент, как JWT собирается и подписывается, а также практические случаи, когда создание токена вручную экономит ваше реальное время.
TL;DR: Генератор JWT превращает полезную нагрузку JSON плюс секрет в подписанный токен. вставьте свои утверждения, выберите HS256, HS384 или HS512, введите секрет и скопируйте токен. The Генератор JWT подписывает с браузером Web Crypto API, поэтому полезная нагрузка и секрет никогда не покидают вашу машину. Используйте его для создания тестовых токенов с известным
sub, установленный срок действия или намеренно истекший срок действияexpчтобы использовать пути ошибок API's. Чтобы прочитать токен обратно, соедините его с JWT декодер, йо-
Что такое JWT и что производит генератор?
Веб-токен JSON - это компактный, безопасный для URL-адресов способ представления набора пунктов формулы изобретения Структура определяется RFC 7519, а подписанная форма, которую почти все имеют в виду под & quot;a JWT, & quot; является веб-подписью JSON, как определено RFC 7515. подписанный токен состоит из трех частей, соединенных точками: header.payload.signature, йо-
Заголовок представляет собой небольшой объект JSON, называющий алгоритм подписи и тип токена, что-то вроде { "alg": "HS256", "typ": "JWT" }. Полезная нагрузка является объектом претензий JSON: о ком токен, когда он истекает, и какие бы пользовательские поля ни добавляло ваше приложение. и заголовок, и полезная нагрузка закодированы в Base64url, что является обычным base64 с двумя заменами символов и без заполнения, точно так, как указывает RFC 7515. Подпись представляет собой хеш с ключом, вычисленный в течение первых двух частей.
Генератор собирает все три. Вы предоставляете полезную нагрузку и секрет, он строит заголовок, кодирует оба сегмента, вычисляет подпись и соединяет их. Выход представляет собой строку, которую вы можете опустить прямо в Authorization: Bearer заголовок, испытательное приспособление или curl команда.
Одна вещь стоит быть резким о up front: подписанный JWT кодируется, а не зашифрован Любой, кто держит токен может Base64url-декодировать полезную нагрузку и читать каждое утверждение в ней. подпись не скрывает содержимое. это только доказывает, что содержимое не было изменено кем-то без ключа. никогда не помещайте пароль, ключ API или что-либо еще, что вы не покажете пользователю внутри полезной нагрузки JWT.
Как работает подписание?
Для семейства HMAC, которым обозначается этот инструмент, подпись есть HMAC(secret, header + "." + payload). HMAC - это конструкция хеша с ключом, определенная RFC 2104, и спецификация JWA, RFC 7518, отображает на нее три имени алгоритма JWT: HS256 использует HMAC с SHA-256, HS384 использует SHA-384, а HS512 использует SHA-512.
Важным свойством является симметрия. один и тот же секрет одновременно создает и проверяет подпись. когда ваш сервер получает токен, он перевычисляет HMAC(secret, header + "." + payload) над полученными первыми двумя сегментами и проверяет, что результат равен сегменту подписи Если один байт полезной нагрузки был изменен, перевычисленный хэш не будет совпадать и проверка не удалась. это вся гарантия целостности.
Потому что он симметричен, секрет - это вся игра Любой, у кого есть секрет, может отчеканить действительные токены для вашей системы, поэтому генератор запускает подпись в вашем браузере через Web Crypto API и никогда нигде не передает секрет Вы можете подтвердить это, открыв свой браузер's вкладка Сеть, пока вы генерируете токен: нет запроса Это имеет большее значение, чем звучит, потому что вставка живого производства подписание секрет в случайный веб инструмент, который телефоны домой будет передавать ключи к вашей аутентификации.
RS256 и ES256, асимметричные алгоритмы, работают по-другому: проверяются знаки закрытого ключа и соответствующий открытый ключ. Это правильный выбор, когда многим службам необходимо проверять токены, но только один должен иметь возможность их выпускать. Этот инструмент намеренно не предлагает их, потому что подписание с ними означает вставку закрытого ключа на веб-страницу, и это привычка, которую стоит никогда не начинать.
Как использовать Генератор JWT
Шаг 1: Запишите полезную нагрузку
Введите свои утверждения как объект JSON. Минимальный пример { "sub": "1234567890", "role": "admin" }, йо- выше sub претензия является предметом, обычно идентификатором пользователя. Вы можете добавить любые пользовательские поля, которые читает ваше приложение, например role, scope, tenant_id, или email. Инструмент сохраняет все, что вы помещаете сюда, точно таким, как написано.
Шаг 2: Добавьте временные претензии
Оставьте выданным и штампуйте инструменты iat с текущим временем Unix. Установите истечение в секундах, чтобы добавить exp претензия вычислена как сейчас плюс это смещение. для пятнадцатиминутного токена доступа введите 900. для одночасового токена введите 3600. Это утверждения, к которым сводится большинство ошибок аутентификации, поэтому правильное их вычисление за считанные секунды с эпохи, а не за миллисекунды, устраняет распространенную ошибку.
Шаг 3: Выберите алгоритм и секрет
Выберите HS256, если у вас нет причины использовать HS384 или HS512. введите секрет подписи в поле. Затем выберите, как интерпретируется секрет: обычный текст использует UTF-8 байтов того, что вы вводите, в то время как base64url и hex декодируют строку сначала в необработанные байты. Этот выбор имеет значение, потому что многие системы хранят секрет, уже закодированный по базе64, и если вы подаете закодированную строку в виде обычного текста, вы создадите подпись, которая не совпадает.
Шаг 4: Скопируйте токен
Подписанный JWT появляется вместе с декодированным предварительным просмотром заголовка и полезной нагрузки, поэтому вы можете подтвердить каждое утверждение перед его использованием. Скопируйте его и вставьте везде, где вам нужно.
Зачем генерировать токен вручную?
Тестирование вашего API's счастливый путь
Когда вы пишете промежуточное программное обеспечение, которое проверяет JWT, вам нужен токен, который должен принять ваш код. Создайте один, подписанный с тем же секретом, который использует ваш верификатор, с действительным exp, и подтвердить запрос возвращает 200. если нет, ошибка в вашей логике проверки, а не в токене. этот единственный шаг изоляции является причиной того, что я обращаюсь к инструменту чаще всего.
Проверка путей сбоев
Надежный API отклоняет правые токены по правильным причинам. Создайте токен с помощью exp уже в прошлом, чтобы подтвердить, что вы возвращаете правильную ошибку с истекшим сроком действия. Создайте один с помощью nbf в будущем, чтобы проверить еще не-действительный путь. сгенерируйте один подписанный с неправильным секретом, чтобы подтвердить ваши проверки подписи запускается. эти отрицательные случаи являются те, которые отправляются непроверенными, и генератор делает их тридцать второй работы.
Воспроизведение ошибки от конкретного пользователя
Поддержка сообщает о проблеме, которая возникает только для учетных записей с определенной ролью. Создайте токен именно с этой role претензия и затронутый пользователь's sub, и вы можете воспроизвести запрос локально, не касаясь производственных данных и не запрашивая у пользователя токен реального носителя, чего вам все равно никогда не следует делать.
Посев местного развития
Новым разработчикам в команде нужен рабочий токен, чтобы попасть в защищенные конечные точки, пока еще строится внешний автомат. сгенерированный токен, подписанный секретом локальной разработки, немедленно разблокирует их.
HS256 против HS384 против HS512: что следует использовать?
| алгоритм | Хэш | Размер подписи | Минимальная длина ключа | Когда использовать |
|---|---|---|---|---|
| HS256 | ША-256 | 32 байта | 32 байта | По умолчанию Быстрый, широко поддерживаемый, безопасный практически для всех видов использования |
| HS384 | ША-384 | 48 байт | 48 байт | Когда политика или стандарт требуют SHA-384 |
| HS512 | ША-512 | 64 байта | 64 байта | Контексты повышенной безопасности или когда вы уже стандартизируете SHA-512 |
Практический ответ HS256, если что-то внешнее не требует иного. RFC 7518 требует, чтобы ключ был как минимум такой же длины, как и хэш-выход, поэтому 32 байта для HS256, 48 для HS384 и 64 для HS512. Генератор предупреждает, когда ваш декодированный секрет короче минимального, потому что короткий ключ ослабляет подпись независимо от имени алгоритма. Более длинный алгоритм с более высоким номером не фиксирует слабый секрет; случайный секрет собственной длины - вот что имеет значение.
Распространенные ошибки и как их избежать
Наиболее частым из них является секретное несоответствие, вызванное кодированием. ваш фреймворк хранит секрет как base64, вы вставляете строку base64 как обычный текст, и теперь ключевые байты отличаются от того, что использует ваш верификатор. подписи никогда не совпадают, и вы преследуете фантомную ошибку. Исправьте это, выбрав правильную секретную кодировку в инструменте, чтобы необработанные ключевые байты были идентичны с обеих сторон.
Второй - запутанные секунды и миллисекунды. зарегистрированные утверждения о времени в RFC 7519 измеряются в секундах с эпохи Unix. JavaScript's Date.now() возвращает миллисекунды. Если вы вычислите exp вы сами и забудьте разделить на 1000, ваш токен, кажется, истекает пятьдесят тысяч лет, которые некоторые строгие верификаторы будут отвергать. Позволяя генератору вычислить утверждения, избегает этого полностью.
Третий - отношение к полезной нагрузке как к частной Это не. Если вы соблазняетесь сохранить секрет в претензии, остановитесь. любой, у кого есть токен, может прочитать его. храните только то, что вам удобно с держателем токена видеть, и храните подлинно секретные данные на сервере.
Где JWT подходят к другим инструментам
После того, как вы сгенерировали токен, естественным следующим шагом будет его чтение обратно. The JWT декодер разбивает любой токен на его заголовок и полезную нагрузку и помечает истекший срок действия exp, который как вы подтверждаете генератор произвел то, что вы намеревались Если вы также генерировать секреты, то хэш-генератор вычисляет хэши SHA на стороне клиента и генератор паролей производит вид длинной случайной строки, которая делает хороший секрет HMAC в первую очередь. если вы хотите понять Base64url шаг за рукой, то Кодер/декодер Base64 показывает то же обратимое преобразование, которое превращает заголовок и полезную нагрузку в их закодированную форму. И когда вам нужен случайный идентификатор, чтобы упасть в a sub или jti претензия, the Генератор UUID дает вам один в правильном формате.
Для более широкой картины того, почему инструменты на основе браузера не позволяют использовать конфиденциальные материалы на сторонних серверах Конфиденциальность данных в онлайн-инстру руководство объясняет модель на стороне клиента и Набор инструментов для веб-разработчиков округляет утилиты, которые хорошо сочетаются с работой с токенами.
Как сервер проверяет созданный вами токен?
Это помогает узнать, что происходит на другой стороне, потому что это объясняет, почему секрет и утверждения должны быть точно правильными Когда ваш API получает токен, библиотека, как jsonwebtoken, jose, или PyJWT делает три вещи по порядку, Он разделяет токен на точках и Base64url-декодирует заголовок, чтобы прочитать alg. Он пересчитывает подпись header.payload используя настроенный секрет и сравнивая его, байт за байт, с сегментом подписи. И он проверяет зарегистрированные претензии: есть exp в прошлом есть nbf в будущем делает iss а aud соответствовать тому, что ожидает API.
Каждый из этих проверок сопоставляется с чем-то, что генератор позволяет вам контролировать. Если проверка подписи не удалась, секрет или его кодировка различаются между двумя сторонами. Если он не работает exp, токен истек, который вы могли специально вызвать для проверки этого пути. если он не работает alg, вы сгенерировали токен с алгоритмом, который верификатор не настроен принять, что само по себе полезно обнаружить. Генерация токенов с преднамеренными вариациями - это то, как вы точно намечаете, какой контроль ваш API обеспечивает соблюдение и какой он молча пропускает.
Слово о alg конкретно заголовок. определяет RFC 7515 none как действительный алгоритм для неподписанного токена, ранние библиотеки доверяли заявленному токену alg: none и пропустить проверку полностью. это классическая уязвимость JWT. Современные библиотеки отклоняют его по умолчанию, но генератор предлагает none опция именно для того, чтобы вы могли запустить неподписанный токен в свой API и подтвердить, что он говорит "нет". Если ваш API когда-либо примет его, вы обнаружите серьезную ошибку.
Как следует обращаться с секретами и хранением токенов?
Секрет, с которым вы подписываетесь, заслуживает такой же заботы, как пароль базы данных Хороший секрет HMAC - это длинная случайная строка, а не запоминающаяся фраза, потому что безопасность HMAC зависит от того, является ли ключ неугадываемым Создание одного с помощью инструмента пароля и сохранение его в конфигурации вашей среды, никогда в управлении источником, является базовым. когда вы его поворачиваете, помните, что каждый токен, подписанный старым секретом, становится недействительным в момент переключения верификатора, поэтому производственные системы обычно поддерживают более одного действительного секрета во время окна вращения.
На стороне клиента, где вы храните готовый токен имеет такое же значение, как и как вы его подписываете. токен в localStorage читается любым JavaScript на странице, поэтому один недостаток межсайтового скриптинга дает злоумышленнику действительный учетный данные. Ан httpOnly, Secure, SameSite файл cookie невидим для сценариев, что замыкает этот путь за счет необходимости защиты CSRF. Общий шаблон - это кратковременный токен доступа, хранящийся в памяти, и более долговечный токен обновления в памяти httpOnly файл cookie. Ничто из этого не меняет способ создания токена, но именно контекст делает сгенерированный токен безопасным для использования, а не обязательством.
часто задаваемые вопросы
Как мне создать JWT?
Вставьте свои утверждения в качестве объекта JSON, выберите алгоритм подписи, такой как HS256, и введите секрет. база инструментов64url-кодирует заголовок и полезную нагрузку, вычисляет подпись HMAC и возвращает готовый токен для копирования. все работает в вашем браузере.
Какие алгоритмы подписи поддерживаются?
HS256, HS384 и HS512, семейство HMAC, а также неподписанный "none" опция для тестирования. RS256 и ES256 намеренно не предлагаются, поскольку они подписываются закрытым ключом, а вставка закрытого ключа на веб-страницу представляет собой угрозу безопасности, которую лучше всего избежать.
Мой секрет отправлен на сервер?
Нет. Подпись полностью выполняется в вашем браузере через Web Crypto API, поэтому секрет и полезная нагрузка никогда не покидают ваше устройство. Вы можете подтвердить это на вкладке DevTools Network, и инструмент продолжает работать в автономном режиме после загрузки.
Как установить истечение срока действия токена?
Введите срок годности в секундах, и инструмент добавит exp претензия равна текущему времени плюс столько секунд. для пятнадцатиминутного токена введите 900. оставьте поле пустым, чтобы опустить exp целиком.
Почему секрет должен быть не менее 32 байт?
RFC 7518 требует ключ HMAC не менее длины хеш-выхода, который составляет 32 байта для HS256, 48 для HS384 и 64 для HS512. Более короткий секрет ослабляет подпись, поэтому инструмент предупреждает, когда декодированный секрет слишком короток.
Могу ли я создать неподписанный токен?
Да. выберите alg none и инструмент производит header.payload. token с пустой подписью. Это только для проверки того, как ваш API обрабатывает неподписанные токены; большинство библиотек отклоняют alg:none по умолчанию, и вы должны тоже.
Зашифрован ли сгенерированный JWT?
№ Подписанный JWT закодирован, а не зашифрован: любой может base64url-декодировать заголовок и полезную нагрузку и прочитать каждое утверждение. подпись только доказывает, что содержимое не было изменено. никогда не помещайте пароли или секреты внутрь полезной нагрузки.
