Как устроены cookie-сессии и токены в Authorization с точки зрения HTTP?

При cookie-сессии браузер сам прикрепляет идентификатор к каждому запросу на домен — удобно, но открывает CSRF; токен в `Authorization` клиент добавляет явно, и чужой сайт не может отправить его от имени пользователя.

Поток cookie-сессии

1. POST /login → Set-Cookie: sid=…; HttpOnly; Secure; SameSite=Lax; Path=/.
2. Каждый следующий запрос несёт Cookie: sid=…, сервер ищет сессию в хранилище вроде Redis. Это stateful, отзыв мгновенный.

Поток с Bearer-токеном

1. Логин возвращает короткий access-токен (часто JWT на 5–15 минут) и refresh-токен.
2. Клиент шлёт Authorization: Bearer <token>, сервер проверяет подпись без обращения к БД.
3. Отозвать JWT до истечения без denylist нельзя — отсюда короткий TTL.
4. Заголовок Authorization в кросс-origin запросе вызывает CORS preflight.

CSRF и SameSite

• Атака: страница злоумышленника отправляет форму на bank.com/transfer, браузер прикладывает cookie жертвы.
• SameSite=Lax (в Chrome — поведение по умолчанию для cookie без атрибута) не отправляет cookie в кросс-сайтовых POST и фоновых запросах, но отправляет при переходе по ссылке. Strict — никогда кросс-сайт. None требует Secure.
• «Сайт» — это регистрируемый домен: evil.example.com для app.example.com — тот же сайт, SameSite не поможет.
• Дополнительно: CSRF-токен, проверка Origin, никаких изменений состояния на GET.

Коротко для собеседования

Выбор между cookie и Bearer-токеном — это выбор между автоматической отправкой с риском CSRF и явной отправкой с хранением токена в JS. Cookie-сессию легко отозвать, JWT — нет, поэтому ему дают короткий TTL; для cookie обязательны HttpOnly, Secure и SameSite.