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

Аутентификация и сессии на бэкенде: как устроены куки, сессии и JWT, где хранить данные и как избежать типичных уязвимостей. Практический минимум для джуна с примерами.

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

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

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

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

Сессии и куки

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

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

JWT-токены

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

Authorization: Bearer eyJhbGciOiJIUzI1NiIsIn...

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

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

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

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

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

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