Stage 10. Cookie vs Session vs JWT
Спор “что лучше: cookie, session или JWT” часто начинается с неверной предпосылки. Эти термины описывают разные уровни архитектуры. Cookie — механизм браузерной доставки/хранения. Session — серверная stateful-модель доступа. JWT — stateless-представление claims с подписью. Поэтому корректный вопрос звучит не “кто победит”, а “какая комбинация лучше решает требования продукта”.
Session-модель сильна там, где нужен централизованный контроль: мгновенный revoke, ограничение активных входов, понятный аудит. Это практично для административных и корпоративных интерфейсов. Цена — поддержка stateful-инфраструктуры и масштабирование session-хранилища.
JWT-модель удобна для распределённых API и микросервисов, где много компонентов должны быстро валидировать доступ локально. Она снижает зависимость от центрального session-lookup на каждый запрос. Цена — более сложный revoke, строгие требования к key-lifecycle и высокие требования к единому профилю claims.
Cookie в этой картине обычно выступает транспортом в браузере. Она может нести session id, refresh token или иной маркер состояния. Поэтому “cookie vs JWT” — категориальная ошибка: cookie и JWT не конкуренты одного уровня.
На практике часто выигрывают гибридные схемы. Например, короткий access token используется для API-вызовов, refresh token хранится в защищённой cookie, а сервер контролирует refresh-сессии. Такой подход балансирует безопасность, производительность и UX, если архитектура и процессы описаны заранее.
Критично выбирать модель не по трендам, а по требованиям. Нужно учитывать типы клиентов (browser, mobile, machine-to-machine), требования мгновенного отзыва доступа, масштаб нагрузки, зрелость команды в операциях с ключами и сессиями, а также compliance-ограничения. Без этой рамки решения становятся эмоциональными и нестабильными.
Ошибки обычно происходят в миграциях. Переход session -> JWT без этапа совместимости ломает авторизацию у части пользователей. Отсутствие rollback-плана делает релиз рискованным. Отсутствие runbook по auth-инцидентам превращает даже локальную проблему в длительный простой.
Хорошая инженерная практика — фиксировать выбор в коротком ADR: контекст, требования, выбранная схема, компромиссы, стратегия миграции и наблюдаемости. Это снижает число повторных споров и помогает новым участникам команды быстро понять, почему архитектура именно такая.
Практический сценарий
Продукт с веб-кабинетом и мобильным приложением попытался полностью перейти на JWT за один релиз. Веб-сценарии с cookie и мобильные токенные сценарии оказались несогласованы, поддержка получила всплеск обращений, а команда несколько недель стабилизировала вход. После перехода на гибридный подход с этапом совместимости и ясными правилами TTL/revoke система стала устойчивой. Этот кейс показывает: лучшая auth-архитектура — не самая “модная”, а та, которую команда может безопасно и предсказуемо эксплуатировать каждый день.