JWT — это просто Base64 в пальто — декодируйте его онлайн за секунды

Вы смотрите на вкладку сети. В заголовке запроса есть строка, которая гласит Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c и ваш первый ответ — «Что вообще это такое?»

Хорошая новость: большая часть этой строки — просто Base64. Этот страшный блок в маске пальто, пытается казаться более таинственным, чем есть. Давайте снимем маску.

Что такое JWT на самом деле

JSON Web Token — это три Base64url-кодированных части, соединённые точками:

• Заголовок – алгоритм и тип токена (например, {"alg":"HS256","typ":"JWT"})
• Полезная нагрузка – утверждения: ID пользователя, роли, срок действия, всё, что решил сервер включить
• Подпись – часть, которая на самом деле обеспечивает безопасность

Заголовок и тело токена не зашифрованы. Они кодируются в Base64url, что означает, что любой, кто имеет токен, может прочитать их — без ключа. Только подпись предотвращает подделку: изменение одного символа в теле токена делает его недействительным.

Чтобы расшифровать тело токена прямо сейчас: возьмите вторую часть (между двумя точками), вставьте её в декодер Base64и вы увидите чистый JSON. Это всё. Это и есть волшебный трюк.

Как быстро расшифровать JWT

Самый быстрый способ: вставьте свой токен в декодер JWT на IOTools. Он разделяет три части, декодирует каждую из них и отображает заголовок и тело в формате JSON — без учётной записи, без настройки, без «входа для разблокировки декодера».

То, что вы сразу увидите в типичном теле токена:

• sub – подлежащее (обычно ID пользователя)
• iat – временная метка (Unix-эпоха)
• exp – срок действия
• iss – издатель
• Любые пользовательские утверждения, которые ваш API вставил: роли, разрешения, уровень плана и т.д.

Если вам нужно просто узнать, истёк ли токен, не подключая полный декодер, используйте проверщик истечения JWT для чтения exp утверждения и указания, сколько времени осталось — или когда он умер.

Три проблемы, которые разрушают разработчиков

1. Истечение, которое вы забыли проверить

The exp поле просто число в теле токена — сервер должен его проверять, но в большинстве старых кодов базы нет проверки, или есть ошибка в обработке временных зон. Если пользователи внезапно вылетают из системы (или внезапно остаются в ней вечно), расшифруйте токен и сравните exp с текущим Unix-временем. Проверщик истечения делает это за один клик. 2. Понимание алгоритма Поле в заголовке указывает на алгоритм, который должен быть использован при проверке. Некоторые старые библиотеки JWT принимали

и полностью пропускали проверку — удаляли подпись и считали любое тело токена действительным. Это известный атака. Всегда проверяйте, чтобы библиотека имела конкретный список разрешённых алгоритмов и отклоняла

Другой вариант: RS256 (асимметричный) против HS256 (симметричный). Атакующий, который знает ваш публичный ключ, может создать токен, изменяя заголовок на alg и подписывая его с помощью публичного ключа как секрет — если библиотека просто доверяет утверждению в заголовке {"alg":"none"} Решение: настройте библиотеку с явным алгоритмом, а не «любой, что указан в токене». none.

3. Секреты в теле токена HS256 Поскольку тело токена Base64-кодировано и не зашифровано, любая информация, которую вы вводите, доступна клиенту (и любому, кто перехватывает токен при передаче по обычному HTTP, хотя вы используете HTTPS везде, верно?). Не вводите пароли, личные данные или внутренние сведения в утверждения токена. Тело токена предназначено для метаданных авторизации — не для хранения чувствительной информации. alg Расшифруйте токен из своего приложения и посмотрите, что там содержится. Вы можете быть удивлены тем, что предыдущий разработчик вставил много лет назад.

JWT против токенов сессии: что на самом деле отличает их

Постоянное спорное вопрос. Вот прямое сравнение:

JWT

Токен сессии

Где хранится состояние

	Внутри токена (без состояния)	На стороне сервера (в базе данных или в памяти)
Отмена	Сложно — токен действителен до	если вы не поддерживаете список заблокированных токенов
Просто — удалите запись сессии	Хорошо подходит для распределённых систем; не требуется общий ресурс сессии exp Требует стиковых сессий или общий ресурс (Redis и т.д.)	Видимость тела токена
Масштабируемость	Клиент может прочитать утверждения (не зашифрованы)	Опака для клиента
Риск хранения	localStorage уязвим к XSS; httpOnly cookie безопаснее	httpOnly cookie (стандартный подход)
Размер токена	Больше — содержит все утверждения в линейном виде	Меньше — просто идентификатор
Лучше подходит для	API, микросервисов, аутентификации между доменами	Традиционных веб-приложений, рендерируемых на сервере
И ни один из вариантов не является универсально лучшим. JWT отлично справляется с аутентификацией без состояния в нескольких сервисах. Токены сессий проще, когда вы контролируете всю структуру и нуждаетесь в мгновенной отмене (например, «выход во всех приложениях» в случае безопасности).	Отладка JWT в реальных рабочих процессах	Вот типичная последовательность, когда что-то сломалось в API, использующем JWT:

Скопируйте токен

из неудачного запроса (заголовок авторизации, параметр запроса или кука — где ваше API его размещает)

Вставьте в

1. чтобы увидеть исходные утверждения — истёк ли токен? Используйте
2. если вы не хотите выполнять вычисления Unix-времени в уме декодер JWT — совпадают ли издатель и аудитория с тем, что ожидает ваш сервис?
3. Проверьте exp Проверьте алгоритм 2. Понимание алгоритма в заголовке — совпадает ли он с настройками сервера?
4. Проверьте iss и aud Проверьте формат подписи
5. — три части? Две? Поддельный токен иногда показывает два участка без подписи Большинство отладок JWT заканчиваются на шаге 3. Токен был выдан с коротким TTL, кэширован где-то, и пришёл просроченным. Это скучно и распространено.
6. Подпись: единственная часть, которая важна Подпись вычисляется как:

. Сервер генерирует её при выдаче токена. При проверке он пересчитывает тот же хеш и сравнивает. Если тело токена было изменено — даже на один символ — хеш не совпадёт, и токен будет отклонён.

Именно поэтому расшифровка JWT для чтения утверждений безопасна и проста, но создание токена без секрета невозможно. Base64 — это костюм; подпись — это замок на двери.

Для асимметричных алгоритмов (RS256, ES256) ключ подписи — это приватный ключ, который никогда не покидает сервера аутентификации. Ключ проверки — это публичный ключ, который может использовать любое приложение — без необходимости делиться секретом. Это правильная архитектура для микросервисов, где несколько сервисов должны проверять токены, но только один должен их выдавать. HMACSHA256(base64url(header) + "." + base64url(payload), secret)JWT — это просто Base64 в пальто — расшифруйте его онлайн за секунды 2

JWT — это просто Base64 в пальто — расшифруйте его онлайн за секунды 1

Токены JWT выглядят устрашающе, но большинство из них — просто Base64. Изучите структуру из трёх частей, как быстро расшифровать утверждения, ошибки, которые ловят разработчиков (путаница с алгоритмами, секреты в теле, ошибки с истечением), и когда использовать JWT вместо токенов сессии.

Вам также может понравиться