jwt токен

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

Структура JWT: три части

JWT представляет собой строку из трёх частей, разделённых точками: header.payload.signature. Каждая часть кодируется в Base64Url.

• Header (заголовок) — JSON-объект с типом токена ("typ": "JWT") и алгоритмом подписи ("alg": "HS256"). Пример: {"alg":"HS256","typ":"JWT"}.
• Payload (полезная нагрузка) — JSON-объект с утверждениями (claims). Стандартные: sub (субъект, обычно ID пользователя), iat (время выпуска), exp (время истечения), iss (издатель), aud (аудитория). Можно добавлять произвольные поля: роли, email, permissions.
• Signature (подпись) — вычисляется как HMAC-SHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) для симметричных алгоритмов или RSA/ECDSA-подпись для асимметричных.

Как работает JWT-аутентификация

Типичный flow:

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

Ключевое свойство — stateless: сервер не хранит сессии. Это позволяет легко масштабировать сервис горизонтально.

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

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

• HS256 (HMAC-SHA256) — симметричный. Один секретный ключ используется и для подписания, и для верификации. Прост, но требует, чтобы все сервисы, проверяющие токен, знали секрет. Подходит для монолитов.
• RS256 (RSA-SHA256) — асимметричный. Приватный ключ подписывает, публичный — верифицирует. Публичный ключ можно безопасно распространять. Подходит для микросервисов и стороннего потребления.
• ES256 (ECDSA-SHA256) — асимметричный на основе эллиптических кривых. Более короткие ключи при той же безопасности, что RS256.

Никогда не используйте алгоритм "none" — это историческая уязвимость, позволявшая обойти проверку подписи.

Безопасное хранение JWT на клиенте

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

• localStorage / sessionStorage — доступен через JavaScript, уязвим к XSS-атакам. Если злоумышленник внедрит скрипт на страницу, он прочитает токен.
• httpOnly cookie — недоступен через JavaScript (защита от XSS), но уязвим к CSRF. Требует CSRF-защиты (SameSite=Strict/Lax, CSRF-токены). Рекомендованный подход для большинства веб-приложений.

Рекомендация: хранить access token в памяти (переменная JavaScript), refresh token — в httpOnly cookie.

Refresh tokens и ротация

Access token должен иметь короткое время жизни (15 минут — 1 час). Для продления сессии без повторного логина используют refresh token — долгоживущий токен (дни/недели), хранящийся в httpOnly cookie. Клиент использует refresh token для получения нового access token. Рекомендуется ротация: при каждом использовании refresh token выдаётся новый и старый инвалидируется (Refresh Token Rotation). Это позволяет обнаружить кражу токена.

Ограничения JWT: нельзя отозвать досрочно

Главный недостаток JWT — невозможность отзыва до истечения срока действия. Если токен скомпрометирован, сервер не может «аннулировать» его без хранения списка отозванных токенов (token blacklist) — что возвращает нас к stateful-модели. Решения: короткое время жизни access token + refresh token с ротацией, либо хранение JWT ID в Redis с TTL для критических операций.

JWT vs сессии: когда что выбирать

Серверные сессии (sessionId в cookie + данные в Redis/БД) подходят для монолитных приложений с одним сервером, когда важна мгновенная инвалидация. JWT оптимален для микросервисов (сервисы верифицируют токен независимо), мобильных API (нет браузерных cookie), OAuth 2.0 / OpenID Connect (JWT = стандартный формат ID Token), и когда нужно масштабировать без общего хранилища сессий.