Краткое введение: аутентификация — подтверждение личности; управление сессией — поддержание состояния аутентифицированного пользователя между запросами. Основные подходы — stateful (сервер хранит сессию, клиент держит идентификатор в куки) и stateless (токены типа JWT, которые несут утверждения и проверяются подписью).
1) Механизмы — обзор
- Серверные сессии + cookie:
- Сервер генерирует идентификатор сессии (session id) и хранит состояние (в памяти, БД, Redis).
- Клиент получает cookie с session id, браузер автоматически отправляет её на каждый запрос.
- JWT (JSON Web Token):
- JWT = header.payload.signature. Сервер подписывает токен (HS256/RS256 и т.д.); токен содержит клеймы (sub, exp, iat, aud, jti…).
- Клиент хранит токен и отправляет его обычно в заголовке Authorization: Bearer или в cookie.
2) Сравнение (плюсы/минусы)
- Хранение состояния:
- Cookie + серверная сессия = сервер контролирует и может мгновенно аннулировать/изменить сессию.
- JWT — статeless: сервер часто не хранит состояние, масштабирование проще, но отзыв токена сложнее.
- Отзыв/аннулирование:
- Серверная сессия: простая инвалидация на сервере.
- JWT: нужен short-lived access token + refresh token/черный список jti/хранение revoked tokens для отзывов.
- Безопасность хранения:
- Если JWT хранится в localStorage — уязвимость к XSS; если в cookie — поведение как у сессий (нужна защита от CSRF).
- Масштабирование/производительность:
- JWT снижает нагрузку на сервер и БД (нет запросов на lookup), но токен может быть большим; проверка подписи CPU‑дешёвая при симметричных/асимметричных алгоритмах.
- Сложность:
- Серверные сессии проще реализовать правильно (особенно для отзывов, ротации, logout).
- JWT даёт удобство SSO, распределённые сервисы (если правильно проверять aud/iss).
3) Основные уязвимости
- XSS (крадут токены в localStorage или доступны cookie без HttpOnly).
- CSRF (при хранении токена в cookie браузер автоматически отправляет его).
- Перехват в сети при отсутствии TLS.
- Replay‑атаки (повторное использование перехваченного токена).
- Неправильная конфигурация JWT: принятие alg=none, отсутствие проверки подписи, слабый секрет для HS256.
- Отсутствие проверки aud/iss/exp/nbf/iat/jti.
- Утечка через логирование токенов или URL (токены не в URL).
- Session fixation (фиксированный session id) и продолжительные неограниченные сессии.
- Insecure cookie attributes (без Secure, HttpOnly, SameSite).
- Неправильная реализация refresh tokens (долгоживущие без контроля/ротации).
4) Практики безопасной реализации (рекомендации)
- Общие:
- Всегда TLS (HTTPS).
- Минимизировать хранение чувствительных данных в токенах/куки.
- Жёсткая проверка на сервере: signature, exp, nbf, aud, iss; валидировать тип алгоритма.
- Логировать и мониторить аномалии сессий/токенов.
- Rate limiting и блокировка при подозрениях (брютфорс).
- MFA для критичных операций.
- Cookie‑специфично:
- Устанавливать флаги: HttpOnly; Secure; SameSite=Lax или Strict (или None + Secure при cross-site).
- Не отправлять токены в URL.
- При необходимости — использовать CSRF‑токены (или опираться на SameSite).
- При logout инвалидация сессии на сервере и очистка cookie.
- JWT‑специфично:
- Использовать короткий lifetime для access token (например минуты/часы) и long‑lived refresh token с хранением и контролем на сервере.
- Хранить refresh token в HttpOnly Secure cookie; использовать rotation (каждый refresh выдаёт новый refresh token и помечает старый как использованный).
- Для критичных систем хранить blacklist/whitelist jti или хранить session id в БД, чтобы иметь возможность отзывать.
- Не хранить секретную/чувствительную информацию в payload (payload не зашифрован по умолчанию).
- Использовать проверенные библиотеки; отключить поддержу "none" алгоритма; при HS256 — сильный секрет, при RS256 — корректное управление ключами.
- Сессии и жизненный цикл:
- Использовать сочетание absolute expiration и idle timeout (максимальное время жизни + таймаут бездействия).
- Инвалидация при смене пароля, критичных настроек, при logout или обнаружении подозрительного поведения.
- Привязка сессии к устройству/IP/агенту с осторожностью (может ломать легитимных пользователей) — лучше факторизация риска.
- Дополнительно:
- Для API: предпочтительнее хранить access token в памяти / HttpOnly cookie и отправлять в Authorization header, избегая localStorage.
- CORS: минимизировать доверенные источники, настроить allowed origins, методы и заголовки.
5) Практический выбор
- Для высоких требований безопасности и необходимости мгновенного отзыва — server‑side sessions.
- Для масштабируемых публичных API / SSO — JWT с короткими access token + безопасными refresh token и серверной логикой для ротации/отзыва.
Краткий вывод: безопасность зависит не только от выбора cookie vs JWT, а от того, как вы храните, защищаете, проверяете и отзываете сеансы/токены. Применяйте TLS, правильные cookie‑флаги, short‑lived access tokens, refresh token rotation и серверный контроль состояний там, где требуется отзыв и высокая безопасность.