Сессионный токен.

Сессионный токен — это учётные данные, которые удерживают пользователя в системе между не хранящими состояние HTTP-запросами. Чаще всего это криптографически случайная строка, хранящаяся на стороне сервера (в базе данных, кэше или подписанной cookie) и отправляемая браузеру в виде cookie с флагами Secure, HttpOnly и SameSite. Сервер использует её как ключ к хранилищу сессий, содержащему идентификатор пользователя, роли и метаданные.

OWASP ASVS и Session Management Cheat Sheet рекомендуют, чтобы идентификаторы сессий несли не менее 64 бит эффективной энтропии (случайное значение около 128 бит), пересоздавались при входе и смене привилегий для противодействия session fixation, а также применяли тайм-ауты по бездействию и абсолютные с инвалидацией на стороне сервера при выходе. Поскольку украденный токен часто обходит пароли и даже MFA, кража сессии — излюбленный приём злоумышленников: расширение Firesheep Эрика Батлера (Eric Butler) 2010 года элементарно «перехватывало» cookie в открытых сетях Wi-Fi, ускорив переход отрасли к повсеместному HTTPS, а современное вредоносное ПО для кражи данных (RedLine, Lumma) собирает активные сессионные cookie, чтобы захватывать учётные записи. Привязка токенов к контексту — HttpOnly против кражи через JavaScript, SameSite для ослабления CSRF, TLS против перехвата в сети и, при необходимости, token binding или отпечатки устройства — ограничивает повторное воспроизведение. К типичным ошибкам относятся предсказуемые ID, токены, раскрытые в URLs, и сессии, которые никогда не истекают.

flowchart LR
  A[Пользователь проходит<br/>аутентификацию] --> B[Сервер генерирует<br/>токен с высокой энтропией]
  B --> C[Set-Cookie: Secure;<br/>HttpOnly; SameSite]
  C --> D[Браузер сохраняет cookie]
  D --> E[Токен отправляется<br/>с каждым запросом]
  E --> F[Сервер ищет<br/>состояние сессии]
  F --> G[Выход / тайм-аут:<br/>инвалидация на сервере]