Сессии против токенов

Два способа помнить вошедшего пользователя

После того как пользователь доказал, кто он, сервер должен помнить этот факт на каждом следующем запросе, потому что сам HTTP не имеет состояния — каждый запрос приходит без памяти о предыдущем. Есть два доминирующих способа нести этот факт «вы вошли», и они стоят на противоположных концах одной оси: где живёт истина.

Серверная сессия держит истину на сервере. При входе сервер создаёт запись — session_id → {user_id, created_at, roles, …} — в хранилище (Postgres, Redis, подписанное зашифрованное cookie-хранилище) и выдаёт клиенту непрозрачный случайный session_id в куке. Кука — это лишь ключ для поиска; сама по себе она ничего не значит. На каждом запросе сервер берёт этот id, находит запись, и именно эта запись — источник истины. Это stateful (с состоянием): сервер держит состояние сессии и обращается к нему на каждом вызове.

Bearer-токен (JWT — частая форма) держит истину внутри токена. При входе сервер собирает небольшой JSON-payload — {sub: user_id, roles, exp} — и подписывает его секретом. Клиент хранит токен и шлёт его на каждом запросе, обычно как Authorization: Bearer <token>. Сервер проверяет подпись тем же секретом и верит заявленным внутри claims — без обращения к БД, без общего хранилища. Это stateless (без состояния): любой сервер с ключом проверки валидирует токен в одиночку. «Bearer» — буквально: владение и есть авторизация. Кто держит токен, того и считают пользователем, ровно как наличные.

Настоящий компромисс: задержка отзыва против стоимости lookup

Токены продают как «масштабируемые, без обращения к БД на запрос», а сессии — как «старые и медленные». Эта подача прячет реальное решение. Честный компромисс — это обмен одной стоимости на другую.

Сессии покупают мгновенный отзыв, расплачиваясь lookup на каждом запросе. Поскольку сервер читает запись сессии на каждом вызове, вы можете изменить или убить её в любой момент: удалить строку для принудительного выхода, переключить поле roles, чтобы понизить пользователя посреди сессии, или инвалидировать все сессии аккаунта после сброса пароля. Цена — этот lookup (Redis GET — субмиллисекунда, чтение Postgres — дольше), и хранилище теперь становится зависимостью на горячем пути каждого аутентифицированного запроса.

Токены покупают stateless горячий путь, расплачиваясь отзывом, которого у вас нет. Нет обращения к хранилищу на запрос, поэтому любой узел с ключом валидирует независимо — это реально помогает флоту stateless-сервисов и кросс-доменным API. Но то же свойство, что убирает lookup, убирает и место сказать «стоп». Подписанный токен валиден, пока не пройдёт его exp; у сервера нет записи, которую можно удалить. Поэтому в момент, когда нужен настоящий отзыв — выход со всех устройств, украденный токен, экстренное понижение прав, — вам приходится прикручивать состояние обратно (denylist, схема short-lived-access плюс refresh), и тут вы снова платите за lookup, а «stateless»-преимущество, ради которого вы это брали, частично исчезло.

Вот зрелая формулировка: вы выбираете не быстро против медленно, а то, где живёт задержка отзыва. Сессии ставят её в ноль и берут плату lookup’ом. Чистые токены выталкивают её на время жизни токена и берут плату инцидентом, когда это окно неверно.

Где ломается каждый

У каждого подхода есть фирменный сбой, и знание их — это то, как вы выбираете.

Сессии ломаются на фиксации сессии и на хранилище. Фиксация сессии: если сервер принимает session id, подсунутый атакующим (например, из крафченой ссылки), а затем повышает этот же id до аутентифицированного при входе, то атакующий — который id уже знает — теперь вошёл как жертва. Фикс не обсуждается и держится на одной строке дисциплины: регенерируйте session id при каждой смене привилегий, особенно при входе, чтобы доаутентификационный id никогда не перетёк в аутентифицированную сессию. Сессии также делают хранилище жёсткой зависимостью: если Redis лежит, никто не аутентифицирован, поэтому ему нужна та же доступность, что и приложению.

Токены ломаются на отзыве и на хранении. Отзыв: разобрано выше — утёкший токен годен до exp, а «выход» — ложь, пока вы не добавили denylist или короткий срок. Хранение: bearer-токен — это наличные, поэтому то, где браузер его держит, решает радиус поражения. В localStorage он читаем любым JavaScript на странице, поэтому одна XSS его выносит; в HttpOnly-куке он невидим для JS (XSS не может его прочитать), но теперь ездит автоматически, и вы снова внесли экспозицию CSRF, которую надо парировать SameSite и анти-CSRF-токенами. Нет места хранения без компромиссов — есть лишь то, чей компромисс вы осознанно обработали.

Как зрелый инженер реально решает

По умолчанию — серверные сессии для first-party веб-приложений: один origin, браузер, который и так хорошо умеет куки, и жёсткое требование, чтобы «выйти» и «забанить» работали сейчас. Lookup на запрос против Redis дёшев и покупает отзыв, который понадобится в день, когда что-то утечёт. Берите токены, когда форма требует statelessness — вызовы сервис-сервис, мобильные и сторонние API-клиенты, или флот, куда не вписывается общее хранилище сессий, — и когда берёте, делайте их короткоживущими access-токенами с серверным refresh, чтобы stateless-часть была ограничена минутами, а отзываемая часть жила в refresh-токене. Неверный ответ — середина: долгоживущий JWT в роли де-факто сессии, который одновременно даёт вам проблему отзыва токена и радиус поражения сессии.