JWT

Содержит метаданные токена: алгоритм подписи (alg) и тип токена (typ). Всегда представляет собой JSON, закодированный в Base64url. Выбор алгоритма напрямую влияет на безопасность всего токена — никогда не принимайте alg из ненадёжного источника.

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

Содержит утверждения: заявления о пользователе и дополнительные метаданные. Также представляет собой JSON, закодированный в Base64url. Данные payload НЕ шифруются, только подписываются — любой, кто перехватит токен, сможет прочитать его содержимое.

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1717200000
}

Криптографическая подпись над закодированными заголовком и payload. Верификация гарантирует, что токен не был изменён. Секретный ключ (HMAC) или приватный ключ (RSA/ECDSA) никогда не включается в состав токена.

HMACSHA256(
  base64url(header) + "." +
  base64url(payload),
  secret
)

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

Использует приватный ключ для подписи и публичный для верификации. Приватный ключ никогда не покидает сервер аутентификации. Публичный ключ можно безопасно распространять через JWKS endpoint, что упрощает верификацию в распределённых системах.

Как RSA, но с меньшими ключами и более быстрой подписью. Обеспечивает эквивалентную безопасность при лучшей производительности.

Нет подписи. Токен с alg:none не имеет гарантий целостности и может быть подделан кем угодно. Ряд JWT-библиотек исторически принимал alg:none, что приводило к критическим уязвимостям.

Некоторые библиотеки принимают токены с alg:none. Злоумышленник может изменить payload и подделать любой JWT. Всегда явно указывайте и проверяйте допустимый алгоритм — никогда не доверяйте значению alg из заголовка токена без дополнительной проверки.

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

JWT без утверждения exp позволяет использовать токены неограниченно. Всегда устанавливайте короткий срок действия и явно проверяйте его при каждой верификации токена.

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

JWT, подписанные с короткими или предсказуемыми секретами, могут быть взломаны методом перебора в офлайн-режиме. Злоумышленник, получив токен, способен перебирать миллиарды ключей в секунду. Используйте криптографически случайные секреты длиной не менее 256 бит.

Принятие JWT без верификации подписи полностью доверяет payload. Это критическая ошибка, позволяющая любому пользователю создавать произвольные утверждения. Всегда верифицируйте подпись перед доверием любому утверждению.

Стандартные JWT (JWS — JSON Web Signature) подписаны, но НЕ зашифрованы. Payload закодирован в Base64url, что тривиально обратимо — любой, кто получит токен, может прочитать его содержимое. JWE (JSON Web Encryption) обеспечивает шифрование, но используется значительно реже и добавляет сложность в управление ключами.

Access токены должны быть кратковременными: 5–60 минут — типичное значение. Долгоживущие токены опасны, поскольку их невозможно отозвать без ведения списка блокировки. Используйте refresh токены — более долгоживущие, хранящиеся безопасно — для получения новых access токенов по мере необходимости.

HttpOnly cookies — наиболее безопасный вариант, недоступный для JavaScript и защищающий от XSS. localStorage удобен, но уязвим к XSS-атакам. Хранение в памяти (JavaScript-переменная) наиболее безопасно, но токен не переживает перезагрузку страницы. Идеального варианта не существует — выбор зависит от модели угроз вашего приложения.

Нет без серверного состояния. Бесстатусная природа JWT означает, что сервер не может аннулировать их напрямую. Решения: короткий срок действия, список блокировки токенов в Redis (с хранением jti), ротация refresh токенов или переход на непрозрачные session токены для чувствительных операций.

Session cookies хранят случайный ID сессии; сервер ищет данные сессии в базе данных. JWT самодостаточны — сервер проверяет подпись без обращения к базе данных, что упрощает горизонтальное масштабирование. Однако JWT сложнее отозвать и они несут больше данных в каждом запросе.

Минимум: sub (ID пользователя), exp (срок действия) и iat (время выдачи). Добавьте iss (издатель) для многосервисных систем. Держите payload небольшим — JWT передаётся с каждым запросом. Не включайте чувствительные данные или большие объекты профиля.

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

PKCE (Proof Key for Code Exchange) — расширение потока авторизационного кода OAuth2, предотвращающее атаки перехвата кода авторизации. Обязательно для публичных клиентов (SPA, мобильные приложения), которые не могут безопасно хранить client secret. Без PKCE злоумышленник, перехвативший код авторизации, может обменять его на токены от вашего имени.