🎯 Зачем спрашивают
- понимаете ли разницу между хранением состояния на сервере и клиенте;
- знаете ли, как работают cookie, localStorage и их trade-offs;
- разбираешься ли в безопасности (XSS, CSRF).
📝 Ответ
Короткий ответ:
Есть несколько сценариев. Рассмотрим один из них — cookies. Последовательность такая:
- Пользователь заходит в приложение, авторизируется
- сервер возвращает авторизационный токен в cookies
- к последующим запросам подцепляется кука с авторизационным токеном. На сервере производится проверка валидности токена
- Если все ок, возвращается контент из авторизованной зоны
Подробнее:
Речь идет про авторизацию пользователя. Существует несколько стратегий:
- Session-based auth
- JWT-based auth
Но смысл у них один и тот же:
- проверить введенные логин и пароль
- если они валидны, выдать пользователю токен (признак/подтверждение того, что пользак авторизован)
- далее, перед тем, как выполнить целевое действие (показать контент, показать диалоги в мессенджере), проверить, валидный ли токен
- если да, то выполнить целевое действие
По факту токен от сервера может вернуться где угодно:
- в cookies (Заголовок Set-Cookies)
- в JSON payload ответа
- в кастомном заголовке (Например, X-Auth-Token)
Плюсы и минусы способов отправки на клиент
Способ отправки на клиент | ✅ Плюсы | ❌ Минусы |
cookies | На клиенте дополнительно не нужно писать код для установки и хранения кук: они автоматически устанавливаются в браузер и подцепляются к дальнейшим запросам
| Если API проектируется и для нативного мобильного приложения, то cookies не подойдут. Так как в мобильных приложениях нет браузера, а значит и нет cookies |
JSON payload | Универсальное решение, если API проектируется и для нативного мобильного приложения. Одна реализация на несколько платформ | Нужно писать код для обработки, хранения (в localStorage, SessionStorage) и подстановки в дальнейшие запросы |
Кастомный заголовок | Универсальное решение, если API проектируется и для нативного мобильного приложения. Одна реализация на несколько платформ | Нужно писать код для обработки, хранения (в localStorage, SessionStorage) и подстановки в дальнейшие запросы |
Если токен возвращается не в cookies, а иначе, то хранить его можно следующих местах:
Плюсы и минусы способов хранения токенов
Где хранить | ✅ Плюсы | ❌ Минусы |
localStorage | - Просто использовать, API доступно в любом браузере.
- Сохраняется между сессиями (после обновления вкладки/закрытия браузера). | - Токен подвержен XSS атаке, так как доступен через JS код
- Нет встроенного механизма «истечения» (нужно реализовывать вручную). |
sessionStorage | - Доступно в браузере без доп. библиотек.
- Автоматически очищается при закрытии вкладки/браузера.
- Подходит для временных сессий. | - Тоже уязвим для XSS (JS имеет доступ).
- Не сохраняется при закрытии вкладки (менее удобно для долгих сессий). |
в замыкании (памяти приложения) | - Не доступен напрямую через XSS (нужно успеть перехватить в рантайме).
- Автоматически очищается при перезагрузке страницы. | - Теряется при обновлении/перезагрузке страницы (нужен re-login или refresh token).
- Более сложное управление (нужно хранить refresh-token отдельно). |
⚖️ Компромиссы
- Cookies (HttpOnly) → безопаснее от XSS, но уязвимы к CSRF. Лечится настройкой SameSite=Lax/Strict или CSRF токен подходом.
- localStorage → легко использовать, но к нему есть доступ через JS (риск XSS уязвимости).
- Session-based auth → требует хранения на сервере (stateful).
- JWT-based auth → stateless, но сложнее отозвать токен.
🔎 Встречные вопросы
- В чем разница между cookies и localStorage?
- Где безопаснее хранить токены: в cookies или localStorage?
- Как отозвать JWT, если он stateless? (blacklist/whitelist в Redis или ставят короткий TTL + refresh token)
🚩 Красные флаги
- Авторизация всегда через localStorage
- Cookies небезопасны, поэтому их не используют
- Нет упоминания про Secure/HttpOnly/SameSite настройки cookies.