Структура JWT токена: устройство, claims и безопасность

Что такое JWT: компактный носитель утверждений

JSON Web Token (JWT) — это открытый промышленный стандарт RFC 7519 для компактной и автономной передачи данных между сторонами в виде JSON-объекта. Главное назначение JWT — подтверждение подлинности (аутентификация) и прав доступа (авторизация) пользователя в распределенных микросервисах и REST API.

Ключевое свойство классического JWT: он автономен (stateless). Серверу не требуется обращаться к общей базе данных сессий при каждом входящем HTTP-запросе. Вся необходимая контекстная информация (ID пользователя, роль, права и срок годности) уже «зашита» в тело токена, а математическая подпись гарантирует, что данные не были подделаны по пути.

Анатомия JWT: три части через точку

Любой корректный JWT токен представляет собой строку, состоящую из трех частей, разделенных точками: header.payload.signature

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

{
  "sub": "user_98412",
  "name": "Alex Miller",
  "role": "editor",
  "iat": 1792929600,
  "exp": 1792933200
}

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  your_secret_key
)

Стандартные зарегистрированные Claims (RFC 7519)

Чтобы микросервисы и библиотеки понимали друг друга без разночтений, спецификация резервирует 7 общепринятых трехбуквенных полей:

5 критических ошибок безопасности при работе с JWT

1. Доверие заголовку «alg: none»

Классическая уязвимость реализации. Если бэкенд берет алгоритм верификации прямо из тела токена без строгой фильтрации, атакующий заменяет заголовок на {"alg": "none"}, стирает подпись и сервер принимает поддельный payload с ролью суперпользователя. На бэкенде алгоритм должен быть жестко зафиксирован в коде: jwt.verify(token, secret, { algorithms: ['HS256'] }).

2. Атака Key Confusion (RS256 vs HS256)

Если система использует асимметричный алгоритм RS256, открытый публичный ключ сервера доступен всем. Злоумышленник меняет в заголовке алгоритм на симметричный HS256 и подписывает поддельный токен... открытым публичным ключом! Незащищенная библиотека, получив токен, берет открытый ключ сервера в качестве секрета HMAC и успешно подтверждает фальшивую подпись.

3. Отсутствие валидации exp и iat

Никогда не полагайтесь на ручную распаковку Base64 без вызова проверки времени. Токен без поля exp становится вечным: если он утечет из сетевых логов или браузера, злоумышленник сохранит бессрочный доступ к аккаунту. Рекомендуемый срок жизни access-токена — от 5 до 15 минут.

4. Утечка токенов через сторонние онлайн-декодеры

Многие разработчики при отладке авторизации копируют боевые токены из консоли браузера и вставляют их в популярные веб-сервисы декодирования. Если сервис отправляет данные на удаленный сервер или пишет запросы в журналы веб-сервера, ваши токены с правами администратора и внутренними URL компании попадают в чужие руки.

Используйте только локальные декодеры. Наш инструмент JWT Декодер выполняет разбор Base64Url и инспекцию полей исключительно на клиенте в вашем браузере: никакие данные не покидают ваше устройство.

5. Уязвимость к XSS при хранении в localStorage

Код из localStorage доступен любому JavaScript-коду на странице. Одна уязвимая npm-библиотека или внедренный баннер может прочитать localStorage.getItem('token') и мгновенно слить его на удаленный сервер. Для веб-приложений токены безопаснее хранить в защищенных cookies с флагом HttpOnly.

Как быстро декодировать JWT в коде без тяжелых библиотек

Так как Header и Payload — это обычный Base64Url, их можно прочитать на клиенте одной функцией без установки тяжелых пакетов:

function parseJwtPayload(token) {
  const base64Url = token.split('.')[1];
  if (!base64Url) throw new Error('Некорректный формат JWT');
  
  const base64 = base64Url.replace(/-/g, '+').replace(/_/g, '/');
  const jsonPayload = decodeURIComponent(
    atob(base64)
      .split('')
      .map(c => '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2))
      .join('')
  );

  return JSON.parse(jsonPayload);
}