Как сервер идентифицирует пользователя приложения
Что проверяют
Для тестировщика это вопрос не про устройство сервера, а про то, знаете ли вы, где искать признак пользователя в запросе и какие проверки из этого следуют. Следом обычно спрашивают, чем 401 отличается от 403 и как убедиться, что один пользователь не видит данные другого.
Как отвечать
Сначала разведите три понятия: идентификация (кто вы), аутентификация (подтверждение паролем, кодом, биометрией) и авторизация (что вам разрешено). Дальше механизмы, которые встречаются на практике:
- сессия в куке: после входа сервер создаёт сессию у себя и отдаёт её идентификатор в
Set-Cookie, браузер присылает его с каждым запросом; - токены: чаще всего JWT в заголовке
Authorization: Bearer ..., короткоживущий access token и refresh token для его обновления; - OAuth 2.0 и OpenID Connect: вход через внешнего провайдера, токены выдаёт сервер авторизации;
- API-ключи и сертификаты: для интеграций между сервисами, иногда mTLS.
Покажите, как это проверяете вы. В DevTools, Charles или Burp смотрите, что именно уходит в запросе, а дальше сценарии:
- без токена: ожидается 401, с чужим токеном к чужому ресурсу 403 или 404;
- подмена id:
/orders/1043вместо своего/orders/1042в URL или теле, это проверка на IDOR; - просроченный токен: 401 и корректное обновление через refresh;
- выход: старую куку или токен отправляют повторно, сессия должна быть недействительна на сервере;
- вход: идентификатор сессии обязан смениться, иначе возможна фиксация сессии.
Где спотыкаются
Путают аутентификацию и авторизацию, а потом не могут объяснить, почему в одном баге ждут 401, а в другом 403.
Считают JWT зашифрованным. Полезная нагрузка это обычный base64url, её читает кто угодно, поэтому паролей и лишних персональных данных там быть не должно.
Проверяют права только через интерфейс. Скрытая кнопка не значит закрытый доступ: тот же запрос, отправленный напрямую через Postman или curl, должен получить отказ от сервера.