Что сервер посылает клиенту при успешной авторизации
Что проверяют
Видите ли вы обмен целиком: не только тело ответа, но и заголовки, куки и то, что клиент с этим делает дальше. Заодно проверяют терминологию, потому что вопрос сформулирован про авторизацию, а описывает результат аутентификации.
Как отвечать
Начните с развилки: схема сессионная или токенная.
В сессионной сервер создаёт сессию у себя и отдаёт её идентификатор заголовком Set-Cookie с флагами HttpOnly, Secure и SameSite. Тело может быть пустым, состояние живёт на сервере, выход убивает сессию мгновенно.
В токенной сервер возвращает в теле короткоживущий токен доступа, его тип Bearer, срок жизни и обычно токен обновления. Токен доступа подписан и проверяется без обращения к хранилищу, поэтому отозвать его мгновенно нельзя, и этим схемы принципиально расходятся.
Рядом часто едут имя, идентификатор и роли, чтобы интерфейс не делал второй запрос. Код ответа обычный успешный, отдельного статуса для входа нет. В схеме с внешним провайдером добавляется токен идентификации и перенаправление на адрес возврата.
Что смотреть тестировщику: выставлены ли флаги куки, не уходит ли токен в строке запроса и в логи, ограничен ли срок жизни, выдаётся ли при входе новый идентификатор сессии взамен прежнего, не кешируется ли ответ, одинаков ли отказ независимо от того, существует ли такой пользователь.
Где спотыкаются
Смешивают аутентификацию и авторизацию. Первая отвечает на вопрос, кто вы, вторая на вопрос, что вам можно; после входа сервер отдаёт результат первой, а роли это уже вход для второй.
Считают, что подписанный токен зашифрован. Подпись защищает от подмены, но содержимое читается кем угодно, поэтому личные данные в полезной нагрузке это утечка.
Останавливаются на теле ответа и не смотрят заголовки. Пропавший HttpOnly у сессионной куки или токен доступа со сроком жизни в сутки видны только там, и это ровно те находки, которых ждут от тестировщика.