Что означает HTTP код 401

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

Различаете ли вы аутентификацию и авторизацию, а значит 401 и 403. Для тестировщика это ещё вопрос о негативных сценариях API: какие случаи должны давать 401 и что проверять в ответе. Следом почти всегда звучит: «А чем 401 отличается от 403?»

Как отвечать

401 Unauthorized означает, что сервер не знает, кто вы: учётных данных нет или они не прошли проверку. Название историческое и сбивает с толку, по смыслу это «не аутентифицирован». По RFC 9110 сервер обязан отправить вместе с 401 заголовок WWW-Authenticate со схемой, например Bearer или Basic, хотя многие API это правило нарушают.

Сравнение, которое ждут:

• 401: личность не установлена. Повторный запрос с правильными данными может пройти;
• 403 Forbidden: личность известна, но прав на ресурс нет. Повторный вход не поможет;
• 404 вместо 403: часть сервисов прячет сам факт существования чужого ресурса. Это осознанное решение, а не баг, но его стоит сверить с требованиями.

Негативные проверки для API:

• нет токена: заголовка Authorization нет вовсе;
• битый токен: неверная подпись, обрезанная строка, лишний пробел после Bearer;
• просроченный токен: истёкший exp у JWT, и отдельно работа обновления через refresh-токен;
• отозванный токен: после выхода или смены пароля старый токен работать не должен;
• тело ответа: без стектрейса и внутренних деталей, текст одинаков для «нет такого пользователя» и «неверный пароль», чтобы нельзя было перебирать логины.

На UI проверяют, что при 401 приложение ведёт на вход или тихо обновляет токен, а не показывает пустой экран. В Postman такие кейсы удобно держать отдельной папкой коллекции.

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

Отвечают, что 401 значит «нет прав». Это 403, и путаница в этом месте почти всегда становится поводом копнуть глубже.

Не знают про WWW-Authenticate или считают его необязательным. На вопрос «что должно быть в ответе» ждут именно его.

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