Аутентификация/сессии: практический минимум

Коротко. Аутентификация — «кто ты» (логин), авторизация — «что тебе можно» (права). Два основных подхода: серверные сессии (состояние на сервере + кука) и JWT-токены (состояние в подписанном токене у клиента). Пароли всегда хранятся хешированными, никогда в открытом виде.

Аутентификация vs авторизация

• Аутентификация — проверка личности (логин/пароль, OAuth).
• Авторизация — проверка прав на действие (роли, доступы).

Сначала система понимает, кто вы, потом — что вам разрешено.

Сессии и куки

Классический подход: после логина сервер создаёт сессию и отдаёт клиенту куку с session id. На каждый запрос браузер шлёт куку, сервер находит сессию.

• ✅ Кука с флагами HttpOnly (недоступна из JS), Secure (только по HTTPS), SameSite.
• Состояние хранится на сервере (в памяти/Redis/БД) — легко отозвать сессию.

JWT-токены

JWT — подписанный токен, который содержит данные о пользователе. Сервер не хранит состояние: проверяет подпись и доверяет содержимому. Плюс — масштабируемость, минус — токен нельзя мгновенно отозвать (решается коротким сроком жизни + refresh-токен).

Authorization: Bearer eyJhbGciOiJIUzI1NiIsIn...

OAuth и вход через соцсети

Кнопка «Войти через Google/GitHub» — это OAuth 2.0. Идея: пользователь не даёт вам пароль, а провайдер (Google) после подтверждения возвращает вашему приложению токен, по которому вы получаете базовые данные профиля. Плюсы для продукта: не нужно хранить пароли и меньше барьер на регистрацию. Джуну достаточно понимать общий поток (redirect → согласие → код → токен), а детали закрывают готовые библиотеки — своими руками OAuth с нуля писать почти никогда не приходится.

Безопасность паролей и токенов

• ✅ Храните пароли как хеш (bcrypt/argon2) с солью — не открытым текстом.
• ✅ Секреты и ключи подписи — в переменных окружения, не в коде.
• ✅ HTTPS обязателен; токены с коротким сроком жизни.
• ❌ Не кладите чувствительные данные в тело JWT — оно читаемо (только подписано, не зашифровано).

Типичные ошибки безопасности

• ❌ Пароли в открытом виде или слабым хешем (MD5/SHA1) — прямой путь к утечке.
• ❌ Секрет подписи JWT в коде и в гите — компрометирует всю авторизацию.
• ❌ Бессрочные токены без возможности отзыва.
• ❌ Отдавать в ответах API лишние поля (хеши, внутренние id, служебные флаги).

Тему безопасности часто спрашивают на собеседовании даже у джуна — знание этих базовых правил заметно выделяет кандидата.

JWT vs серверная сессия — коротко

Сессия на сервере: проще инвалидировать, привычная модель cookie+store. JWT: удобен в distributed/API, но отзыв токена сложнее, раздувание payload — ошибка. Для джуна важнее: https-only cookie, не хранить токен в localStorage без понимания XSS, пароли только hash (bcrypt/argon2), reset-поток отдельно.

На собесе часто спрашивают CSRF vs XSS и зачем SameSite. Связка с API: REST.

Следующий шаг в бэкенде

Примените идеи из «Аутентификация/сессии: практический минимум» к своему учебному проекту или к одной вакансии на этой неделе. Соберите минимальный API: CRUD + валидация + одна таблица в БД + README с запуском. Дальше: REST API, SQL, auth, деплой. План — бэкенд 2026, обзор роли — backend starter.

Как применить «Аутентификация/сессии: практический минимум» на практике

Пройдите материал не как статью, а как задание. Выпишите 3 тезиса из разделов (Аутентификация vs авторизация; Сессии и куки; JWT-токены) и напротив каждого — действие на 30–90 минут: что сделаете руками, какой файл/репозиторий появится, как поймёте что готово. Без этого колонки «изучил» в голове не конвертируются в оффер.

Связка с соседними материалами: REST, REST API, SQL, auth, деплой. Не читайте всё подряд — возьмите один следующий URL и закройте его артефактом в git до конца недели. Если роль ещё не выбрана, сначала профессии и 5 вакансий-ориентиров, потом возвращайтесь к этой теме.

На собеседовании по теме «Аутентификация/сессии: практический минимум» вас почти всегда просят пример из практики. Подготовьте 60–90 секунд: задача → что сделали → результат/ограничение. Даже учебный пример звучит сильнее пересказа теории.

Частые вопросы

Сессии или JWT?
Для монолита и веба часто удобнее сессии (легко отзывать). JWT хорош для API и микросервисов. Для джуна важно понимать оба.

Чем хешировать пароли?
bcrypt или argon2. Обычные хеши (MD5/SHA) для паролей небезопасны.

JWT — это шифрование?
Нет, обычный JWT только подписан. Содержимое можно прочитать, поэтому секреты в него не кладут.

Где хранить JWT на клиенте?
Безопаснее — в HttpOnly-куке; localStorage уязвим к XSS. Это тоже частый вопрос на собесе.

Материал «Аутентификация/сессии: практический минимум» имеет смысл только вместе с практикой: один артефакт в git на этой неделе важнее десяти вкладок с теорией. Если застряли на выборе роли — начните с профессий и одной вакансии-ориентира.