JWT как механизм сессий

JWT часто используют как замену серверным сессиям в браузерных приложениях. Это антипаттерн — JWT проектировался для других задач.

Проблемы JWT как сессий

Избыточный размер

Простой идентификатор пользователя занимает 6 байт в cookie, но ~304 байта в JWT — увеличение в 51 раз. На 100 000 просмотров в месяц это дополнительные ~24 МБ трафика.

База данных всё равно нужна

Главное преимущество JWT — stateless, сервер не хранит сессии. На практике почти каждый запрос требует загрузки пользователя из БД для проверки прав, отображения данных, CRUD-операций. Stateless-преимущество теряется.

Двойная криптография

Если JWT хранится в cookie, то подпись выполняется дважды: сам JWT подписан, и cookie тоже криптографически подписан фреймворком. Двойная работа без дополнительной безопасности.

Невозможность отзыва

JWT валиден до истечения срока. Для отзыва нужен blacklist токенов, что по сути — та же серверная сессия, только сложнее.

Уязвимость к XSS

В localStorage токен доступен любому JavaScript на странице. Одна XSS-уязвимость — и токен украден. Серверные сессии с HttpOnly cookies не подвержены этой атаке.

Когда JWT подходит

• Межсервисное взаимодействие — service-to-service в микросервисах
• Мобильные приложения — secure storage на устройстве
• CLI-клиенты — автоматизация и скрипты
• Федеративная аутентификация — SSO, OpenID Connect

Альтернативы для браузеров

• Серверные сессии с Redis/memcached — время ответа менее 5 мс
• BFF-паттерн — токены на сервере, браузеру только HttpOnly cookie
• Spring Security Form Login — встроенный механизм с HttpOnly cookies

См. также

• BFF-паттерн — безопасная аутентификация для браузеров
• Access и Refresh токены — жизненный цикл JWT-токенов