Открыть сервисСервис
Главная → Блог → JWT — формат токенов аутентификации

JWT — формат токенов аутентификации

JWT (JSON Web Token, произносится «джей-дабл-ю-ти») — открытый стандарт (RFC 7519) представления утверждений (claims) в виде компактного формата на основе JSON, предназначенного для обмена данными между двумя сторонами. Токен состоит из трёх частей, закодированных в Base64URL и соединённых точками, и криптографически подписывается (или шифруется) отправителем, чтобы получатель мог проверить подлинность и целостность содержимого. JWT широко применяется в веб-аутентификации, механизмах single sign-on (SSO), OAuth 2.0 и защите API.

Структура токена

JWT имеет вид строки из трёх компонентов, разделённых символом .:

`` xxxxx.yyyyy.zzzzz ``

ЧастьНазваниеСодержимое
ПерваяHeader (заголовок)JSON с типом токена (typ: "JWT") и используемым алгоритмом подписи (alg: HS256, RS256, ES256 и др.)
ВтораяPayload (полезная нагрузка)JSON с утверждениями (claims): стандартные (iss, sub, exp, iat, aud) и произвольные пользовательские
ТретьяSignature (подпись)Криптографическая подпись, вычисленная по первым двум частям

Каждая из первых двух частей кодируется алгоритмом Base64URL без дополнения нулями. Важно, что Base64 — это не шифрование: содержимое payload легко прочитать любому, у кого есть токен. Конфиденциальные данные в JWT помещать нельзя — только идентификаторы, роли, сроки действия.

Подпись и алгоритмы

JWT поддерживает два семейства алгоритмов подписи:

  • HMAC (HS256, HS384, HS512) — симметричные, используют один общий секрет у отправителя и получателя. Подходят, когда токен подписывает и проверяет один и тот же сервис.
  • RSA и ECDSA (RS256, RS384, RS512, ES256, ES384, ES512) — асимметричные: подписывающая сторона использует приватный ключ, проверяющая — публичный. Такая схема удобна для распределённых систем, где множество сервисов должны проверять токены, но не должны знать секрет подписи.

Существует также алгортим none, формально допускающий отсутствие подписи; его использование в продакшене считается критической уязвимостью и во всех библиотеках отключено по умолчанию.

Процесс аутентификации

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

  1. Клиент отправляет учётные данные (логин и пароль) на сервер аутентификации.
  2. Сервер проверяет их и формирует JWT: заполняет payload (например, sub — идентификатор пользователя, exp — срок действия), подписывает токен секретным ключом.
  3. Токен возвращается клиенту, который хранит его (обычно в localStorage или в httpOnly-cookie) и передаёт в заголовке Authorization: Bearer <token> при каждом запросе к защищённому API.
  4. Сервер проверяет подпись публичным ключом или секретом, убеждается, что срок действия не истёк, и выполняет запрос.

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

Стандартные утверждения (claims)

RFC 7519 определяет набор зарегистрированных утверждений:

  • iss (issuer) — издатель токена;
  • sub (subject) — субъект, к которому относится токен (обычно ID пользователя);
  • aud (audience) — предполагаемый получатель;
  • exp (expiration time) — момент истечения срока действия (Unix-время);
  • nbf (not before) — момент, до которого токен недействителен;
  • iat (issued at) — время выдачи;
  • jti (JWT ID) — уникальный идентификатор токена (для защиты от повторного использования).

Применение

  • Аутентификация в SPA и мобильных приложениях — основной сценарий, заменяющий серверные сессии.
  • OAuth 2.0 и OpenID Connect — в OIDC ID-токен и access-токен являются JWT.
  • Межсервисная аутентификация — подписанные токены позволяют сервисам доверять данным друг друга без общего хранилища сессий.
  • Безопасный обмен данными (JWT Compact Serialization) — в формате JWE токен может быть ещё и зашифрован.

Ограничения и риски

  • Невозможность мгновенного отзыва. Токен действителен до exp; для отзыва нужен дополнительный механизм.
  • Размер. Токен передаётся в каждом HTTP-запросе, поэтому payload должен быть компактным.
  • Утечка при XSS. Если JWT хранится в localStorage, JavaScript-код на странице может его украсть; использование httpOnly-cookie снижает риск.
  • Алгоритм none и подмена alg. Сервер обязан жёстко проверять алгоритм подписи и не доверять полю alg из заголовка токена.
  • Отсутствие шифрования по умолчанию. Стандартный JWT (JWS) лишь подписывает данные; для шифрования применяется расширение JWE.

Стандарты и экосистема

Спецификация JWT входит в семейство стандартов JOSE (JSON Object Signing and Encryption), описанных в RFC 7515–7519. Для популярных языков программирования существуют зрелые библиотеки: PyJWT и python-jose (Python), jsonwebtoken (Node.js), java-jwt (Java), go-jose (Go), Microsoft.IdentityModel.Tokens (.NET). Реализации поддерживают все основные алгоритмы, проверку exp/nbf, работу с JWK (JSON Web Key) и JWKS (наборы ключей).

Источники:

  • RFC 7519 — JSON Web Token (JWT)
  • RFC 7515 — JSON Web Signature (JWS)
  • RFC 7517 — JSON Web Key (JWK)
  • OWASP cheat sheet «JSON Web Token (JWT)»

Похожие материалы

Заметили ошибку или не согласны с информацией в статье? Напишите нам support@bfometr.ru