Сессии против JWT, и почему logout — сложно

Две модели: где живёт состояние авторизации

Прежде чем выбирать модель авторизации или отлаживать logout, который «не сработал», нужно понять одно: где сервер хранит истину о том, кто ты? Ответ на этот вопрос определяет всё остальное — что стоит отзыв, сколько round-trip тратит запрос и возможно ли «забань сейчас» одной строкой. Каждая схема авторизации отвечает на один вопрос на каждом запросе — «этот вызывающий действительно тот, за кого себя выдаёт?» — и две доминирующие модели отвечают на него из противоположных мест.

Stateful серверные сессии держат истину на сервере. Логин создаёт строку сессии в хранилище (Redis или таблица БД); клиент получает назад только непрозрачный, ничего не значащий id сессии в httpOnly cookie. Каждый последующий запрос несёт этот id, и сервер ищет сессию, чтобы узнать, кто ты.

// Stateful: cookie держит непрозрачный id; сервер держит истину.
// Логин пишет строку; каждый запрос читает её обратно.
await store.set(`sess:${sid}`, { userId, roles }, { ttlSec: 3600 });
res.cookie('sid', sid, { httpOnly: true, secure: true, sameSite: 'lax' });

// На каждом запросе guard резолвит личность через ПОИСК:
const session = await store.get(`sess:${req.cookies.sid}`); // 1 чтение store
if (!session) throw new UnauthorizedException();             // отозван → мгновенно вышел

Stateless JWT держит истину в токене. Токен и есть claims (sub, roles, exp), подписанные сервером. Верификация локальна: проверь подпись и exp, доверяй payload. Никакого хранилища, никакого поиска.

// Stateless: токен несёт claims, подписанные. Verify локален — ноль поисков.
const token = jwt.sign({ sub: userId, roles }, SECRET, { expiresIn: '15m' });

// На каждом запросе: проверь подпись + exp, затем доверяй payload. Никакого I/O.
const claims = jwt.verify(req.headers.authorization?.slice(7), SECRET);

Эта разница — весь урок. Сессии стоят одного чтения store на запрос и заставляют делить это хранилище между всеми инстансами приложения (sticky-сессии или центральный Redis — общее состояние и есть цена). JWT стоит ноля поисков и масштабируется горизонтально без чего-либо общего — и именно поэтому его нельзя отозвать: нет строки, которую можно удалить.

Проблема logout: тривиальна с сессиями, сложна с JWT

«Разлогинь этого пользователя везде» / «забань этот аккаунт СЕЙЧАС» — это одна и та же операция, и она брутально обнажает асимметрию.

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

// Сессии: отзыв ЕСТЬ удаление. Мгновенно, глобально, готово.
await store.del(`sess:${sid}`);        // одно устройство
await store.del(`user-sessions:${userId}`); // или каждое устройство — следующий поиск промахнётся

С JWT такой строки нет. Токен само-валидируется: любой держатель байтов авторизован до exp, точка. Ты можешь очистить cookie — но это затронет только кооперирующего клиента. Токен, скопированный вором или переигранный скриптом абьюзера, нетронут. Нет серверной рукоятки, за которую можно потянуть.

Поэтому ты симулируешь отзыв, и каждый вариант — это компромисс:

// (1) КОРОТКИЙ TTL access-токена — сожми неотзываемое окно до минут.
//     Ради этого существуют refresh-токены (разбирается отдельно): отзывает сам exp.
jwt.sign({ sub: userId }, SECRET, { expiresIn: '15m' }); // окно ≤ 15 минут

// (2) DENYLIST отозванных jti до их exp — но это снова поиск на каждом запросе,
//     возвращающий общее состояние, ради ухода от которого ты взял JWT. Гибрид.
if (await denylist.has(claims.jti)) throw new UnauthorizedException(); // +1 чтение

// (3) PER-USER tokenVersion (он же minIssuedAt) — бампай его на logout-all /
//     смене пароля; отвергай любой токен, выпущенный раньше. Один индексированный поиск,
//     инвалидирует ВСЕ токены пользователя разом. Прагматичная золотая середина.
const u = await users.findById(claims.sub);               // 1 индексированное чтение
if (claims.tokenVersion !== u.tokenVersion) throw new UnauthorizedException();

Вариант (1) ограничивает окно урона, но никогда не закрывает его по требованию. Вариант (2) даёт точный отзыв на каждый токен, но возвращает чтение на запрос, ради ухода от которого ты ушёл в stateless. Вариант (3) — тот, на котором оседает большинство команд: единственная индексированная колонка, бампнутая один раз, убивает каждый токен пользователя — правильный инструмент для «забань сейчас» и «разлогинь все устройства».

Где какая модель уместна — и почему реальные системы гибридны

Тянись к сессиям, когда мгновенный глобальный отзыв — жёсткое требование, а общее хранилище приемлемо: классические server-rendered веб-приложения, банкинг, админ-консоли — везде, где «убей этот доступ прямо сейчас» должно стать правдой в следующую миллисекунду. Тянись к JWT, когда центральное хранилище сессий — это узкое место: stateless-микросервисы, мобильные/API-клиенты и межсервисная авторизация, где каждый хоп, перепроверяющий один Redis, сериализовал бы твой fan-out.

Большинство зрелых систем отказываются от бинарности и идут в гибрид: короткоживущий stateless access-JWT (ноль поисков на горячем пути) в паре со stateful refresh-токеном, хранимым в БД (отзываемым). Ты уже держишь серверное состояние на границе refresh, так что отзыв refresh-токена останавливает выпуск новых access-токенов — а короткий access-TTL осушает те, что уже выданы. Это и есть архитектура, дающая масштаб JWT и отзываемость сессий, с неотзываемым окном, ограниченным access-TTL.

Несколько JWT-граблей едут с тобой в любом случае. Размер токена: JWT в заголовке или cookie куда крупнее непрозрачного id сессии и едет на каждом запросе — держи claims минимальными, никогда не запихивай весь профиль пользователя. Расхождение часов: exp сравнивается с часами каждого сервера, так что допусти небольшой leeway (несколько секунд), иначе нода с убежавшими часами отвергнет ещё валидные токены. Флаги cookie важны для обеих моделей: httpOnly не даёт JS читать токен, Secure держит его вне открытого текста, SameSite притупляет CSRF.