Подготовка к тех.интервью

Как сервер узнаёт авторизацию пользователя на сайте?

Пользователь авторизован на сайте. Как сервер узнает об этом с последующими другими заходами, что «я – авторизованный пользователь»?

Теория по задаче

Суть задачи: HTTP «без состояния»

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

После установления аутентифицированной сессии её идентификатор (session ID / token) временно становится эквивалентом «самого сильного» метода аутентификации в приложении, поэтому его утечка равносильна захвату аккаунта.

Варианты хранения состояния

На практике применяются два основных семейства подходов: «сессионный идентификатор в cookie и состояние на сервере» и «самодостаточный токен (например JWT) и минимум состояния на сервере».
В обоих случаях сервер «узнаёт» пользователя исключительно из того, что пришло в запросе (например, заголовок Cookie или Authorization), поскольку браузер должен повторно отправлять идентификатор при последующих заходах.

Ниже — компактная схема обмена для cookie-сессии (самый распространённый вариант для сайтов):

  1. POST /login (credentials)
  2. 200 OK + Set-Cookie: SID=...; Path=/; Secure; HttpOnly
  3. GET /profile + Cookie: SID=...
  4. Сервер читает SID -> находит сессию -> определяет userId/roles -> авторизует доступ
Передача идентификатора в URL (query-параметрах) повышает риск утечки через историю браузера, логи и заголовок Referer, поэтому предпочтительным механизмом обмена идентификатором считается cookie.

Сервер после успешного логина генерирует криптографически случайный session id, сохраняет на сервере запись сессии (например, sid -> userId, expiresAt, roles) и отправляет sid браузеру через Set-Cookie, чтобы браузер автоматически возвращал его в Cookie на следующих запросах.
По спецификации cookies сервер может отправлять состояние через Set-Cookie, а клиент при последующих запросах возвращает его в заголовке Cookie в пределах области действия (domain/path) и срока жизни cookie.

Пример HTTP-обмена (ключевой «след» авторизации — cookie SID):

HTTP/1.1 200 OK
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly

GET /account HTTP/1.1
Host: example.com
Cookie: SID=31d4d96e407aad42

Для защиты session id в cookie обычно фиксируются атрибуты, снижающие риск XSS/CSRF/утечки в сети: Secure (только HTTPS), HttpOnly (недоступно JS API), SameSite (ограничение на cross-site отправку cookie).
HttpOnly ограничивает доступ к cookie из «не-HTTP API» (например, из JavaScript API браузера), что является ключевой мерой против кражи session id через XSS.

Практически важные правила жизненного цикла: session id следует регенерировать после смены уровня привилегий (особенно после логина), а при logout/истечении срока — инвалидировать сессию на сервере и очистить cookie на клиенте.
Таймауты необходимо обеспечивать на сервере (idle/absolute), поскольку клиентские ограничения времени могут быть подменены атакующим.

Таблица различий подходов (что именно «говорит» серверу, что пользователь авторизован):

ПодходЧто приходит в каждом запросеГде хранится «кто это»Типичные плюсыТипичные минусы
Cookie-сессия (server-side)Cookie: SID=...В серверном хранилище сессий (Redis/DB/память)Лёгкая инвалидация (удаление записи), меньше данных на клиентеНужна инфраструктура хранения/масштабирования сессий
Bearer tokenAuthorization: Bearer <token>Обычно токен несёт права/идентичность или ключ к нимУдобно для API и мобильных клиентов«Кто владеет токеном — тот и пользователь», требуются меры защиты от утечки
JWT (частный случай токена)Часто так же Authorization: Bearer ...Часть состояния внутри JWT claimsМеньше запросов к БД на проверку сессииНужны строгие сроки (exp), сложнее отзыв/инвалидация без доп. механизмов
Для JWT критично корректно обрабатывать срок действия: claim exp задаёт момент, после которого токен не должен приниматься.

Кратко: HTTP сам по себе не «помнит» логин; авторизация между запросами поддерживается передачей идентификатора (чаще cookie SID) в каждом запросе и проверкой этого идентификатора сервером по серверному хранилищу сессий или по токену (Bearer/JWT) с обязательными мерами защиты (Secure, HttpOnly, SameSite, таймауты, регенерация session id).