Как реализовать авторизацию и что происходит после отправки логина и пароля на бэк

Что проверяют

Понимает ли кандидат весь путь запроса на вход: что уходит на сервер, как хранится пароль, что возвращается и чем сессия отличается от токена. Для QA дополнительно ждут список того, что на этом флоу нужно тестировать.

Как отвечать

Сначала развести термины: аутентификация отвечает на вопрос «кто ты», авторизация на вопрос «что тебе можно». Форма логина это первое, роли и права это второе.

Что происходит по шагам:

1. Клиент шлёт POST /login по HTTPS, креды лежат в теле запроса, а не в query-строке: адрес попадает в логи прокси, историю браузера и заголовок Referer.
2. Сервер валидирует формат, ищет пользователя по логину.
3. Сверяет пароль. Пароль не шифруется, а хешируется медленным алгоритмом с солью: bcrypt, scrypt, argon2. Соль хранится внутри самого хеша, поэтому сравнение идёт функцией verify(введённый, сохранённый_хеш), а не повторным хешированием и сравнением строк.
4. При совпадении создаётся сессия или пара токенов.

Ответ сервера:

• Успех: 200 и либо Set-Cookie с идентификатором сессии (флаги HttpOnly, Secure, SameSite), либо JWT access плюс refresh.
• Неуспех: 401 с одинаковым сообщением для «нет такого пользователя» и «неверный пароль». Разные тексты дают перечисление логинов. 403 это уже про недостаток прав, на форме входа он не к месту.

Разница подходов важна: серверная сессия отзывается мгновенно, достаточно удалить запись. JWT самодостаточен, сервер его не хранит, поэтому до истечения срока он остаётся валидным даже после нажатия «Выйти». Отсюда короткий TTL у access и отзыв на уровне refresh либо чёрный список.

Дальше клиент прикладывает Authorization: Bearer <token> или куку, сервер проверяет подпись и срок, достаёт роли и решает вопрос доступа.

Что проверять тестами:

• неверный пароль, несуществующий логин: текст ответа и время отклика совпадают;
• пустые поля, пробелы по краям, регистр логина, очень длинный пароль, юникод;
• инъекции в поля логина;
• брутфорс: срабатывает ли рейт-лимит или блокировка после N попыток;
• протухший, подделанный и обрезанный токен, токен с изменённой ролью;
• logout: старый токен и старая кука больше не работают;
• доступ к чужому ресурсу с валидным токеном (IDOR);
• флаги куки в ответе, редирект после входа, работа в нескольких вкладках.

Где спотыкаются

Говорят «пароль шифруется на бэке», хотя хеширование необратимо и в этом весь смысл. Второе: не могут объяснить, почему выход из системы с JWT сложнее, чем с сессией.