Как декодировать и проверять JWT-токены в браузере

Если вы работали с любой современной системой веб-аутентификации — OAuth 2.0, OpenID Connect или собственным API — вы почти наверняка сталкивались с JWT-токенами. Они появляются в заголовках Authorization, в cookie, в локальном хранилище и в сессиях отладки в 2 часа ночи, когда поток входа загадочно сбоит. Понимание того, что на самом деле содержит JWT, как его читать и как замечать частые проблемы, делает отладку аутентификации значительно быстрее.

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

Что такое JWT?

JWT расшифровывается как JSON Web Token и определён в RFC 7519. JWT — это компактный, URL-безопасный токен, кодирующий набор утверждений (claims) — заявлений о субъекте, обычно пользователе — в формате, который можно проверить и которому можно доверять. Ключевое свойство JWT в том, что он самодостаточен: сам токен несёт всю информацию, нужную серверу для аутентификации запроса, без обращения к базе данных.

JWT выглядит так:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfODQyMTkiLCJuYW1lIjoiSmFuZSBEb2UiLCJlbWFpbCI6ImphbmUuZG9lQGV4YW1wbGUuY29tIiwicm9sZXMiOlsidXNlciIsImVkaXRvciJdLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJodHRwczovL2FwaS5leGFtcGxlLmNvbSIsImlhdCI6MTczODM2ODAwMCwiZXhwIjoxNzM4MzcxNjAwLCJqdGkiOiI3ZjNhOWI0Yy0xZDJlLTQ1NmYtYWJjZC04OTAxMjM0NTY3ODkifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

На первый взгляд он выглядит как абракадабра. Но у него очень точная структура: три раздела в кодировке Base64URL, разделённые точками. У каждого раздела своё назначение.

Трёхчастная структура: Header.Payload.Signature

Часть 1: заголовок

Первый сегмент, до первой точки — это заголовок (header). Это объект JSON в кодировке Base64URL, описывающий тип токена и алгоритм подписи. В декодированном виде заголовок из примера выше выглядит так:

{
  "alg": "HS256",
  "typ": "JWT"
}

Поле alg задаёт алгоритм подписи. Распространённые значения, с которыми вы столкнётесь:

• HS256 — HMAC с SHA-256. Использует общий секретный ключ. И эмитент, и проверяющий должны иметь один и тот же секрет. Распространён в монолитных приложениях.
• RS256 — RSA-подпись с SHA-256. Использует пару открытый/закрытый ключ. Эмитент подписывает закрытым ключом; проверяющие проверяют открытым. Распространён в распределённых системах и у OAuth-провайдеров.
• ES256 — ECDSA с P-256 и SHA-256. Как RS256, но с использованием эллиптических кривых — более короткие ключи, тот же уровень безопасности. Предпочтителен в современных высокопроизводительных системах.
• none — без подписи. Никогда не принимайте это в продакшене. Печально известная уязвимость возникает, когда серверы принимают неподписанные токены, потому что клиент изменил alg на "none".

Часть 2: полезная нагрузка

Второй сегмент — это полезная нагрузка (payload) — собственно данные, которые несёт токен. Это тоже объект JSON в кодировке Base64URL. Декодированная полезная нагрузка из нашего примера:

{
  "sub": "usr_84219",
  "name": "Jane Doe",
  "email": "jane.doe@example.com",
  "roles": ["user", "editor"],
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "iat": 1738368000,
  "exp": 1738371600,
  "jti": "7f3a9b4c-1d2e-456f-abcd-890123456789"
}

Полезная нагрузка содержит два типа утверждений: зарегистрированные утверждения, определённые спецификацией JWT, и частные/пользовательские утверждения, добавленные вашим приложением (вродеname, email и roles выше).

Часть 3: подпись

Третий сегмент — это подпись (signature). Она вычисляется, беря заголовок в кодировке Base64URL, точку, полезную нагрузку в кодировке Base64URL и подписывая результат алгоритмом и ключом, указанными в заголовке. Для HS256:

HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

Подпись обеспечивает целостность: если кто-то изменит хотя бы один символ в заголовке или полезной нагрузке после выдачи токена, подпись становится недействительной и проверка не проходит. Не зная секрет подписи (или закрытый ключ эмитента для RS256/ES256), злоумышленник не может подделать действительный токен.

Справочник стандартных утверждений JWT

Почему утверждение exp критически важно

Утверждение exp — это Unix-метка времени, число секунд с 1 января 1970 года (UTC). В нашем примере "exp": 1738371600. Чтобы преобразовать это в читаемую человеком дату, можно использовать JavaScript:

new Date(1738371600 * 1000).toUTCString()
// → "Sat, 01 Feb 2026 01:00:00 GMT"

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

Декодировщик JWT BrowseryTools автоматически считывает утверждения exp и iat и отображает их как читаемые человеком даты рядом с сырыми Unix-метками времени, так что вам никогда не придётся считать в уме.

Распространённые сценарии отладки JWT

Токен истёк (401 Unauthorized)

Самая частая ошибка JWT. Сервер отверг токен, потому что текущее время позже значенияexp. Решение: реализуйте поток обновления токена с помощью более долгоживущего refresh-токена или просто переаутентифицируйтесь. Вставьте токен в декодировщик, чтобы точно подтвердить, когда он истёк.

Неправильная аудитория

Если ваш API проверяет утверждение aud, а токен был выдан для другой аудитории (например, токен, выданный для https://api-staging.example.com, отправляется на https://api.example.com), сервер его отвергнет. Декодируйте токен и проверьте полеaud, чтобы убедиться, что оно совпадает с тем, что ожидает принимающий сервис.

Несовпадение алгоритма

Если ваш сервер ожидает RS256, но получает токен, подписанный HS256 (или наоборот), проверка не проходит. Это может случиться при ротации ключей или при смене auth-провайдеров. Сверьте поле alg в декодированном заголовке с тем, что ваш сервер настроен принимать.

Подпись недействительна

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

JWT против сессионных токенов: когда какой использовать

JWT и традиционные сессионные токены решают одну задачу — идентификацию аутентифицированного пользователя в нескольких запросах — но делают это по-разному, и ни один не лучше повсеместно.

Традиционные сессионные токены — это непрозрачные случайные строки (например, UUID), хранимые на стороне сервера в хранилище сессий (Redis, база данных). На каждом запросе сервер ищет токен в хранилище и извлекает данные пользователя. У сервера полный контроль: аннулирование сессии немедленно отзывает доступ.

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

• Используйте JWT для микросервисов без состояния, распределённых систем, мобильных API и кросс-доменной аутентификации (потоки OAuth/OIDC). Держите сроки истечения короткими.
• Используйте сессионные токены, когда нужна возможность немедленного отзыва (выход, приостановка аккаунта, инциденты безопасности) или когда все ваши сервисы делят быстрое хранилище сессий.

Как пользоваться декодировщиком JWT BrowseryTools

Откройте декодировщик JWT и вставьте свой токен в поле ввода. Инструмент сразу разбивает токен по двум точкам и отображает:

• Панель заголовка: декодированный JSON, показывающий alg, typ и любые другие поля заголовка. Полезно для определения алгоритма подписи с одного взгляда.
• Панель полезной нагрузки: полный декодированный JSON со всеми утверждениями. Метки времени отображаются как в сыром Unix-формате, так и в читаемых человеком датах UTC, чтобы вы сразу видели истечение без расчётов в уме.
• Статус истечения: чёткий индикатор, показывающий, действителен ли токен сейчас, уже истёк или ещё не активен (на основе nbf). Если истёк, вы видите ровно, как давно это произошло.
• Сегмент подписи: сырая подпись в кодировке Base64URL, показанная для справки. Инструмент не проверяет подпись (для этого нужен секрет или открытый ключ), но декодирует и отображает всю информацию, нужную для отладки.

Нет отправки формы, нет серверного запроса, нет доступа к буферу обмена сверх того, что вы явно вставляете. Разбор токена происходит полностью в JavaScript, работающем во вкладке вашего браузера.

Декодируйте свой JWT-токен прямо сейчас

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