Как проверять авторизацию в запросах с авторизацией и без, и обрабатывать отсутствие токена

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

Знаете ли вы разницу между аутентификацией и авторизацией и какие коды за ними стоят: 401 и 403. Следом обычно спрашивают про чужие данные: что будет, если с валидным токеном запросить ресурс другого пользователя.

Как отвечать

Разложите проверки на матрицу из состояния токена, эндпоинта и роли:

• нет заголовка Authorization: защищённый эндпоинт отвечает 401, в ответе нет данных и стектрейса, по стандарту есть WWW-Authenticate;
• невалидный токен: пустое значение, Bearer без токена, мусорная строка, испорченная подпись, чужая схема вроде Basic. Везде 401, а не 500;
• просроченный токен: 401, а клиент должен сходить за новым через refresh-токен, не выкидывая пользователя. Если сервер обещает отзыв при logout, старый токен после выхода не работает;
• валидный токен без прав: 403. Сюда же IDOR: пользователь A подставляет в URL id ресурса пользователя B и не получает ни данных, ни 200;
• публичные эндпоинты: работают без токена и с просроченным токеном тоже;
• JWT: alg: none, изменённая роль в payload без переподписи, токен с другого окружения. Всё отклоняется.

На UI отсутствие токена проверяют так: удалить его из cookie или localStorage и обновить страницу. Ожидается редирект на логин с возвратом на исходную страницу после входа.

Инструменты: Postman с токенами в переменных окружения и отдельной коллекцией негативных кейсов, pytest с requests или REST Assured для автотестов, Burp Suite для подмены токена на лету.

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

Путают 401 и 403 и принимают любой код ошибки. 401 значит «не знаю, кто вы», 403 значит «знаю, но нельзя».

Проверяют только отсутствие токена и забывают про валидный токен чужого пользователя. Именно IDOR чаще всего приводит к утечкам.

Смотрят на код и не смотрят в тело. Стектрейс или разные сообщения «user not found» и «wrong password» сами по себе дефекты.