developer • 9 мин чтения • Обновлено: 2026-09-20

Архитектура claims и уязвимости безопасности токенов JWT

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

Строение токена: Header, Payload, Signature

Строка токена состоит из трёх независимых сегментов в формате Base64URL, разделённых точками:

HEADER.PAYLOAD.SIGNATURE

1. Header (Заголовок): содержит метаданные о токене — тип ("typ": "JWT") и криптографический алгоритм подписи ("alg": "HS256" или "RS256");
2. Payload (Полезная нагрузка): JSON-объект с данными (клеймами / claims). Здесь хранятся идентификатор пользователя sub, его права и роли;
3. Signature (Цифровая подпись): вычисляется сервером от строки base64Url(Header) + "." + base64Url(Payload) с использованием секретного ключа.

Важнейшее правило: Payload не зашифрован, а лишь закодирован! Любой человек в браузере может прочитать его содержимое. Ни в коем случае нельзя сохранять в JWT пароли, номера карт или приватные ключи.

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

Полезный инструмент: Полезная нагрузка токена кодируется в Base64Url (подробнее в статье про Base64 кодирование).

Полезный инструмент: Для подписи применяется хэш-функция (проверьте результат через генератор хэшей SHA-256).

Стандартные зарегистрированные клеймы (Registered Claims)

Спецификация RFC 7519 резервирует несколько 3-буквенных параметров:

• exp (Expiration Time): Unix Timestamp истечения срока действия. При его превышении сервер обязан отклонить токен с ошибкой 401 Unauthorized;
• iat (Issued At): время выпуска токена;
• nbf (Not Before): дата, до наступления которой токен недействителен;
• iss (Issuer): эмитент токена (например, https://auth.company.com);
• sub (Subject): уникальный идентификатор субъекта (пользователя);
• aud (Audience): целевая аудитория (для какого сервиса выпущен токен).

Алгоритмы подписи: HS256 vs RS256

Выбор алгоритма определяет безопасность архитектуры микросервисов:

• HS256 (HMAC-SHA256): симметричный алгоритм. Сервер авторизации и все сервисы-потребители используют один и тот же секретный пароль. Если один сервис взломан, злоумышленник получает ключ и может подделывать любые токены;
• RS256 (RSA-SHA256): асимметричная криптография. Сервер авторизации подписывает токен приватным ключом, а микросервисы проверяют подпись общедоступным публичным ключом (JWKS). Это исключает компрометацию всей системы при взломе клиентских API.

Часто задаваемые вопросы (FAQ)

В спецификации JWT предусмотрен режим без подписи (alg: none). Некоторые старые библиотеки доверяли заголовку от клиента и принимали модифицированные токены с правами администратора. В современных библиотеках алгоритм проверки жестко фиксируется на бэкенде.

Токены доступа критически важно хранить в куках с флагами HttpOnly, Secure и SameSite=Strict. Это на 100% защищает токен от кражи через XSS-атаки с внедрением вредоносного JavaScript.

Воспользуйтесь инструментом «Декодер JWT» на Utilora.ru: токен парсится строго в браузере без отправки данных на сервер.

Скопировано в буфер обмена!