Что означает HTTP-статус 401 Unauthorized?

Ответ

HTTP 401 Unauthorized — это код состояния клиентской ошибки, который означает, что запрос не был применён, потому что ему не хватает действительных учётных данных для аутентификации. Сервер "не знает", кто такой клиент, и отказывает в доступе.

Ключевое отличие от 403 Forbidden:

  • 401 Unauthorized: "Я тебя не узнаю. Предъяви пропуск (учётные данные)."
  • 403 Forbidden: "Я тебя узнал, но у тебя нет прав на этот ресурс."

Типичные причины и сценарии:

  1. Отсутствие заголовка аутентификации: Запрос отправлен без Authorization.
  2. Неверный или просроченный токен: Переданный Bearer/JWT токен некорректен, подписан неверно или истёк.
  3. Неправильные логин/пароль при использовании Basic Auth.
  4. Попытка доступа к защищённому ресурсу без предварительного логина.

Пример запроса и ответа:

### Запрос с неверным токеном
GET /api/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer expired_or_invalid_token

### Ответ сервера
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="Access to profile", error="invalid_token", error_description="The access token expired"
Content-Type: application/json

{
  "error": "Unauthorized",
  "message": "Invalid or expired authentication token"
}

Заголовок WWW-Authenticate: Сервер может отправить этот заголовок, чтобы указать клиенту схему аутентификации, которую следует использовать (например, Basic, Bearer). Это часть стандарта HTTP.

Что делать при получении 401:

  1. На стороне клиента (тестировщика/разработчика):
    • Проверить корректность формирования заголовка Authorization.
    • Убедиться, что токен активен и не истёк.
    • Выполнить запрос на обновление токена (если используется refresh token flow).
    • Перелогиниться в системе для получения новых учётных данных.
  2. На стороне сервера (если вы администрируете API):
    • Проверить конфигурацию сервера аутентификации.
    • Убедиться в правильной валидации подписи и срока действия токенов.

Тестирование: При тестировании API сценарии с неверными или отсутствующими учётными данными должны всегда возвращать 401, а не 500 или 403.

Ответ 18+ 🔞

А, слушай, вот эта штука, 401-я, блядь! Это ж классика, ёпта! Представь: ты подходишь к двери в какой-нибудь закрытый клуб, а тебя швейцар, сука, останавливает и такой: «А ты кто такой? Пропуск покажи». А ты ему: «Да я Вася!». А он тебе: «А я тебя, Вася, не знаю, иди нахуй». Вот это и есть HTTP 401 Unauthorized.

Короче, сервер тебе прямо так и говорит: «Чувак, я тебя в глаза не видел. Нет у тебя ни паспорта, ни ксивы, ни просроченного билета в театр — нихуя. Иди авторизуйся сперва».

А вот главная фишка, чтобы не спутать с 403-ей, блядь!

  • 401 Unauthorized: «Я тебя не знаю. Предъяви документы, а потом поговорим». Ты — неопознанный летающий объект.
  • 403 Forbidden: «О, Петрович, привет! Я тебя знаю. Но в этот сортир тебе нельзя, он только для директора». Ты опознан, но доступ закрыт — сосалка.

Когда эта хрень обычно вылезает? Да элементарно:

  1. Вообще забыл сказать, кто ты. Отправил запрос, а в нём пусто, ни одного заголовка Authorization. Сервер смотрит на это и думает: «Ну и наглость, блядь».
  2. Токен протух или кривой. Ты суёшь свой JWT-токен, а он, сука, как вчерашняя шаурма — уже не айс. Истёк, подпись не бьётся, хуйня какая-то.
  3. Логин с паролем — полная шляпа. Используешь Basic Auth, а там «admin:12345». Сервер пробует, блюёт и выдаёт 401.
  4. Полез сразу в защищённое место, не залогинившись. Это как пытаться заказать еду в ресторане, минуя стойку администратора. Не прокатит.

Смотри, как это выглядит вживую:

### Ты пытаешься стукнуться в API с каким-то левым токеном
GET /api/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer ya_ustal_i_poshel_na_xyi

### А сервер тебе такой ответ, с сарказмом:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="Access to profile", error="invalid_token", error_description="The access token expired"
Content-Type: application/json

{
  "error": "Unauthorized",
  "message": "Invalid or expired authentication token"
}

Видишь этот заголовок WWW-Authenticate? Это сервер тебе, как мамаша нерадивому ребёнку, на пальцах объясняет: «Дурачок, используй схему Bearer, вот тебе даже realm подсказал. И токен твой — говно».

Что делать, если влетел в эту 401-ю?

  • Если ты на стороне клиента (тестировщик или фронтендер):
    • Первым делом — не бздеть. Проверь, не отвалился ли у тебя заголовок с авторизацией. Бывает, сука, кривые руки.
    • Глянь на свой токен — не протух ли он, как молоко на солнце. Если да — иди обнови его (refresh token в студию!).
    • Совсем хана? Придётся перелогиниться, получить свежие креды.
  • Если ты на стороне сервера (бэкендер или админ):
    • Проверь, не съехала ли конфигурация твоего сервиса аутентификации. Может, ключи для подписи токенов поменялись, а ты и не в курсе.
    • Убедись, что валидация токенов работает чётко: и сроки, и подписи.

Для тестировщиков отдельный наказ: если шлёшь запрос без авторизации или с левыми данными, а в ответе не 401, а какая-то 500-я ошибка или, что хуже, 403 — это пиздец и баг. Сервер должен чётко отличать «незнакомца» от «недоступного ресурса для знакомого». Волнение ебать!