JSON Web Token (JWT): руководство по аутентификации и безопасности

Что такое JWT?

JWT (JSON Web Token) — компактный, безопасный для URL формат токена, определённый в RFC 7519, используемый для безопасного обмена информацией между сторонами.

JWT состоит из трёх частей: Header, Payload и Signature. Эти три части разделены точками (.): xxxxx.yyyyy.zzzzz

Обеспечивает stateless-аутентификацию. Вместо хранения данных сессии в базе данных сервер отправляет токен клиенту. Клиент отправляет токен с каждым запросом.

Случаи использования: аутентификация API, SSO (единый вход), аутентификация между микросервисами, авторизация мобильных приложений.

Структура JWT

Header: содержит тип токена (JWT) и алгоритм подписи (HS256, RS256, ES256). Кодируется в Base64URL.

Payload: содержит claims. Registered claims (iss, sub, aud, exp, nbf, iat, jti), public claims и private claims. Кодируется в Base64URL.

Signature: закодированные в Base64URL header и payload объединяются точкой и подписываются секретным ключом. HS256 использует HMAC-SHA256, RS256 использует RSA-SHA256.

Пример: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Поток использования JWT

1. Пользователь отправляет запрос на endpoint входа с именем пользователя и паролем.

2. Сервер проверяет учётные данные и создаёт JWT. Токен возвращается в теле ответа или в cookie.

3. Клиент сохраняет токен в localStorage или httpOnly cookie.

4. В последующих запросах клиент отправляет JWT как Bearer-токен в заголовке Authorization: Authorization: Bearer <token>

5. Сервер проверяет токен (проверка подписи и срока действия). Если действителен, обрабатывает запрос; если нет, возвращает 401 Unauthorized.

Риски безопасности

Кража токена: токен в localStorage может быть украден через XSS-атаку. Используйте httpOnly cookie для снижения риска XSS.

Время жизни токена: короткоживущий access-токен (15-30 мин) + долгоживущий refresh-токен (7-30 дней). Ротируйте refresh-токен при каждом использовании.

Путаница алгоритмов: алгоритм 'none' или переключение RS256→HS256. Устанавливайте алгоритм как константу на стороне сервера, не берите из токена.

Чувствительные данные: payload JWT кодируется в Base64, не шифруется. Не помещайте чувствительные данные (пароль, кредитная карта) в payload.

Размер токена: JWT больше, чем cookie сессии. Отправляется с каждым запросом. Держите payload минимальным.

Лучшие практики

Короткоживущие токены: access-токен 15-30 минут, refresh-токен 7-30 дней. Истёкшие токены автоматически становятся недействительными.

httpOnly + Secure + SameSite cookie: храните токен в httpOnly cookie. JavaScript не может получить доступ (защита от XSS). Secure (только HTTPS). SameSite (защита от CSRF).

Ротация токена: refresh-токен обновляется при каждом использовании. Старый refresh-токен становится недействительным. Ограничивает доступ злоумышленника при краже токена.

Blacklist/отзыв: используйте blacklist для отзыва токенов. Храните отозванные токены в Redis. Используйте для выхода и инцидентов безопасности.

Алгоритм: RS256 (асимметричный) рекомендуется для production. Подписывайте приватным ключом, проверяйте публичным. HS256 (симметричный) только для одного сервиса.

Валидация: проверяйте подпись, issuer (iss), audience (aud), срок действия (exp) при каждом запросе. Убедитесь, что все проверки пройдены, прежде чем доверять токену.

JWT vs аутентификация на основе сессий

JWT: stateless, простое горизонтальное масштабирование, идеально для микросервисов, большой размер токена, сложно отозвать.

Session: stateful, требует серверного хранения, нужен sticky session или shared store для горизонтального масштабирования, маленький размер токена, легко отозвать.

Критерии выбора: архитектура микросервисов → JWT. Монолитное приложение → Session. Мобильное приложение → JWT. Высокие требования безопасности → Session + JWT hybrid.

Гибридный подход: короткоживущий JWT (access-токен) + session store (refresh-токен). Объединяет преимущества обоих.