Перейти к основному содержимому

[Lv1] В чём различия между Session-based и Token-based аутентификацией?

Частый уточняющий вопрос на собеседовании: понимаете ли вы различия между традиционной Session и современным Token? Освойте следующие ключевые моменты, чтобы быстро структурировать свои мысли.

1. Основные концепции обеих моделей аутентификации​

Session-based аутентификация​

  • Состояние хранится на сервере: После первого входа пользователя сервер создаёт Session в памяти или базе данных и возвращает Session ID, сохранённый в Cookie.
  • Последующие запросы зависят от Session ID: Браузер автоматически отправляет Session Cookie для того же домена, и сервер находит соответствующую информацию о пользователе по Session ID.
  • Распространена в традиционных MVC / монолитных приложениях: Сервер отвечает за рендеринг страниц и поддержание состояния пользователя.

Token-based аутентификация (например, JWT)​

  • Состояние хранится на клиенте: После успешного входа генерируется Token (который может содержать информацию о пользователе и правах) и сохраняется на фронтенде.
  • Token отправляется с каждым запросом: Обычно размещается в Authorization: Bearer <token>. Сервер верифицирует подпись для получения информации о пользователе.
  • Распространена в SPA / микросервисах: Бэкенду нужно только верифицировать Token без хранения состояния пользователя.

2. Сравнение потоков запросов​

ШагSession-basedToken-based (JWT)
Успешный входСервер создаёт Session, возвращает Set-Cookie: session_id=...Сервер выдаёт Token, возвращает JSON: { access_token, expires_in, ... }
ХранениеCookie браузера (обычно httpOnly)Выбор фронтенда: localStorage, sessionStorage, Cookie, Memory
Последующие запросыБраузер автоматически отправляет Cookie; сервер ищет информацию о пользователеФронтенд вручную добавляет заголовок Authorization
ВерификацияЗапрос к Session StoreВерификация подписи Token или проверка чёрного/белого списка
ВыходУдаление Session на сервере; возврат Set-Cookie для очистки CookieФронтенд удаляет Token; принудительная инвалидация требует чёрного списка или ротации ключей

3. Сводка преимуществ и недостатков​

АспектSession-basedToken-based (JWT)
Плюсы- Cookie отправляется автоматически, просто на стороне браузера
- Session может хранить большие объёмы данных
- Легко отозвать и принудительно завершить сессию		- Stateless, горизонтально масштабируется
- Подходит для SPA, мобильных, микросервисов
- Token работает между доменами и устройствами
Минусы- Сервер должен поддерживать Session Store, потребляя память
- Распределённые развёртывания требуют синхронизации Session		- Token больше по размеру, передаётся с каждым запросом
- Не может быть легко отозван; требует механизмов чёрного списка / ротации ключей
Риски безопасности- Уязвимость к CSRF-атакам (Cookie отправляется автоматически)
- Если Session ID утёк, его необходимо немедленно очистить		- Уязвимость к XSS (если хранится в доступном месте)
- Если Token украден до истечения, запросы могут быть воспроизведены
Сценарии использования- Традиционный Web (SSR) + один домен
- Серверный рендеринг страниц		- RESTful API / GraphQL
- Мобильные приложения, SPA, микросервисы

4. Как выбрать?​

Задайте себе три вопроса​

  1. Нужен ли вам кросс-доменный или мультиплатформенный общий статус входа?

    • Да → Token-based более гибкий.
    • Нет → Session-based проще.

  2. Развёртывание на нескольких серверах или в микросервисах?

    • Да → Token-based снижает потребность в репликации или централизации Session.
    • Нет → Session-based прост и безопасен.

  3. Есть ли высокие требования к безопасности (банки, корпоративные системы)?

    • Более высокие требования → Session-based + httpOnly Cookie + защита от CSRF остаётся мейнстримом.
    • Лёгкие API или мобильные сервисы → Token-based + HTTPS + Refresh Token + стратегия чёрного списка.

Типичные комбинированные стратегии​

  • Корпоративные внутренние системы: Session-based + синхронизация через Redis / базу данных.
  • Современные SPA + мобильные приложения: Token-based (Access Token + Refresh Token).
  • Крупномасштабные микросервисы: Token-based (JWT) с верификацией на API Gateway.

5. Шаблон ответа на собеседовании​

«Традиционная Session хранит состояние на сервере и возвращает session ID в Cookie. Браузер автоматически отправляет Cookie с каждым запросом, что хорошо подходит для Web-приложений на одном домене. Недостаток в том, что сервер должен поддерживать Session Store, а развёртывание на нескольких серверах требует синхронизации. В отличие от этого, Token-based (например, JWT) кодирует информацию о пользователе в Token, который хранится на клиенте, и фронтенд вручную включает его в Header с каждым запросом. Этот подход stateless, что делает его подходящим для SPA и микросервисов и более простым в масштабировании. Что касается безопасности, Session нужно защищать от CSRF, а Token — от XSS. Если мне нужен кросс-доменный доступ, мобильное устройство или интеграция нескольких сервисов, я выберу Token. Для традиционных корпоративных систем с серверным рендерингом я выберу Session с httpOnly Cookies.»

6. Заметки для уточняющих вопросов на собеседовании​

  • Session → Акцент на защите от CSRF, стратегиях синхронизации Session и частоте очистки.
  • Token → Акцент на месте хранения (Cookie vs localStorage), механизме Refresh Token и чёрном списке / ротации ключей.
  • Можно упомянуть распространённый компромиссный подход в корпоративной среде: хранение Token в httpOnly Cookie, что также может сочетаться с CSRF Token.

7. Ссылки​