403 Запрещено против 401 Несанкционированные ответы HTTP

2786

Для веб-страницы, которая существует, но для которой пользователь не имеет достаточных привилегий (они не вошли в систему или не принадлежат к соответствующей группе пользователей), какой надлежащий HTTP-ответ должен обслуживать?

401 Unauthorized?
403 Forbidden?
Что-то другое?

То, что я прочитал о каждом из них, пока не очень ясно о разнице между ними. Какие варианты использования подходят для каждого ответа?

VirtuosiMedia
источник
358
401 «Не авторизован» должен быть 401 «Не авторизован», проблема решена!
Кристоф Русси
47
Я не помню, сколько раз я и мои коллеги возвращались к stackoverflow для этого вопроса. Возможно, в стандартах HTTP следует рассмотреть возможность изменения имен или описаний для 401 и 403.
neurite
На самом деле, я получаю другую версию этой ошибки. как "os_authType был 'any' и был отправлен недопустимый файл cookie". Так не в состоянии понять, как решить это. Погуглил много времени, нашел причины, но не нашел решения.
Сандип Ананд
@ Да нет, новый RFC7231 устарел RFC2616. 403 имеет другое значение сейчас.
fishbone
1
@fishbone вы также не заметили, что код состояния 401 был удален из этого RFC: D
Barkermn01

Ответы:

4117

Четкое объяснение от Даниэля Ирвина :

Проблема с 401 Unauthorized , кодом состояния HTTP для ошибок аутентификации. И это все: для аутентификации, а не для авторизации. Получив ответ 401, сервер скажет вам: «Вы не аутентифицированы - либо не аутентифицированы вообще, либо аутентифицированы неправильно - но, пожалуйста, повторите аутентификацию и попробуйте снова». Чтобы помочь вам, он всегда будет включать заголовок WWW-Authenticate, который описывает, как пройти аутентификацию.

Этот ответ обычно возвращается вашим веб-сервером, а не вашим веб-приложением.

Это также что-то очень временное; сервер просит вас попробовать еще раз.

Итак, для авторизации я использую 403 Запрещенный ответ. Это постоянно, это связано с логикой моего приложения, и это более конкретный ответ, чем 401.

При получении ответа 403 сервер говорит вам: «Извините. Я знаю, кто вы, я верю, кем вы себя называете, но у вас просто нет разрешения на доступ к этому ресурсу. Может быть, если вы спросите системного администратора, вы получите разрешение. Но, пожалуйста, не беспокойте меня снова, пока ваше затруднительное положение не изменится.

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

Еще один приятный графический формат того, как следует использовать коды состояния http.

введите описание изображения здесь

JPReddy
источник
43
По умолчанию сообщение IIS 403 «Это общая ошибка 403 и означает, что прошедший проверку пользователь не авторизован для просмотра страницы», что, по-видимому, согласится.
Бен Чалленор
333
@JPReddy Ваш ответ правильный. Тем не менее, я ожидаю, что 401 будет называться «Не авторизован», а 403 - «Не авторизован». Это очень сбивает с толку, что 401, который имеет отношение к Аутентификации, имеет формат, сопровождающий текст "Несанкционированный" .... Если только я не хорошо владею английским (что вполне возможно).
p.matsinopoulos
64
@ZaidMasud, согласно RFC, это толкование неверно. Ответ Cumbayah понял это правильно. 401 означает «вам не хватает правильного разрешения». Это означает, что «если вы хотите, вы можете попытаться аутентифицировать себя». Таким образом, и клиент, который не аутентифицировал себя правильно, и клиент, прошедший надлежащую аутентификацию и пропустивший авторизацию, получат 401. 403 означает «Я не буду отвечать на это, кем бы вы ни были». RFC ясно заявляет, что «разрешение не поможет» в случае 403.
Давиде Р.
84
401 - ошибка аутентификации, 403 - ошибка авторизации. Просто как тот.
Шахрияр Иманов
30
Вы пропустили "Ну, это мой взгляд на это в любом случае :)" при копировании из его сообщения в блоге, и, к сожалению, его мнение ошибочно. Как утверждают другие, 403 означает, что вы не можете получить доступ к ресурсу независимо от того, кем вы аутентифицированы. Обычно я использую этот код состояния для ресурсов, которые заблокированы диапазонами IP-адресов или файлами в моем веб-корне, к которым я не хочу прямого доступа (т. Е. Скрипт должен обслуживать их).
Кайл
403

См. RFC2616 :

401 Несанкционированный:

Если в запрос уже включены учетные данные авторизации, то ответ 401 указывает, что в авторизации было отказано для этих учетных данных.

403 Запрещено:

Сервер понял запрос, но отказывается его выполнить.

Обновить

Из вашего варианта использования видно, что пользователь не аутентифицирован. Я бы вернул 401.


Изменить: RFC2616 устарел, см. RFC7231 и RFC7235 .

Одед
источник
21
Спасибо, это помогло уточнить это для меня. Я использую оба - 401 для неаутентифицированных пользователей, 403 для аутентифицированных пользователей с недостаточными разрешениями.
VirtuosiMedia
52
Я не понизил голос, но я нахожу этот ответ довольно вводящим в заблуждение. 403 запрещено более целесообразно использовать в контенте, который никогда не будет обслуживаться (например, файлы .config в asp.net). это либо тот, либо 404. imho, было бы неуместным возвращать 403 для чего-то, к чему можно получить доступ, но у вас просто не было необходимых учетных данных. Мое решение было бы дать сообщение об отказе в доступе с возможностью изменения учетных данных. это или 401.
Мел
27
«Ответ ДОЛЖЕН включать поле заголовка WWW-Authenticate (раздел 14.47), содержащее запрос, применимый к запрашиваемому ресурсу». Казалось бы, если вы не хотите использовать аутентификацию в стиле HTTP, код ответа 401 не подходит.
Brilliand
8
Я верну Биллианду сюда. Заявление: «Если в запрос уже включены полномочия авторизации». Это означает, что это ответ на запрос, предоставивший учетные данные (например, ответ на попытку аутентификации RFC2617). По сути, это позволяет серверу сказать: «Неверная пара аккаунт / пароль, попробуйте еще раз». В поставленном вопросе пользователь предположительно аутентифицирован, но не авторизован. 401 никогда не будет подходящим ответом на эти обстоятельства.
ldrut
6
Brilliand прав, 401 подходит только для HTTP-аутентификации.
Juampi
296

Чего не хватает другим ответам, так это того, что следует понимать, что Аутентификация и Авторизация в контексте RFC 2616 относятся ТОЛЬКО к протоколу HTTP-аутентификации RFC 2617. Аутентификация по схемам вне RFC2617 не поддерживается в кодах состояния HTTP и не рассматривается при принятии решения использовать 401 или 403.

Краткое и краткое

Unauthorized указывает, что клиент не прошел проверку подлинности RFC2617, и сервер инициирует процесс проверки подлинности. Запрещено указывает, что клиент аутентифицирован по RFC2617 и не имеет авторизации, или что сервер не поддерживает RFC2617 для запрошенного ресурса.

Это означает, что если у вас есть свой собственный процесс входа в систему «по-отдельности» и вы никогда не используете HTTP-аутентификацию, 403 всегда является правильным ответом, а 401 никогда не должен использоваться.

Подробный и углубленный

От RFC2616

10.4.2 401 Несанкционированный

Запрос требует аутентификации пользователя. Ответ ДОЛЖЕН включать поле заголовка WWW-Authenticate (раздел 14.47), содержащее запрос, применимый к запрашиваемому ресурсу. Клиент МОЖЕТ повторить запрос с подходящим полем заголовка Авторизация (раздел 14.8).

а также

10.4.4 403 Запрещено Сервер понял запрос, но отказывается его выполнить. Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться.

Первое, что нужно иметь в виду, это то, что «Аутентификация» и «Авторизация» в контексте этого документа относятся конкретно к протоколам HTTP-аутентификации из RFC 2617. Они не относятся к любым протоколам аутентификации, которые вы, возможно, создали сами. использование страниц входа и т. д. Я буду использовать «логин» для ссылки на аутентификацию и авторизацию, отличные от RFC2617

Таким образом, реальная разница не в том, в чем проблема, или даже в том, если есть решение. Разница в том, что сервер ожидает, что клиент будет делать дальше.

401 указывает, что ресурс не может быть предоставлен, но сервер ЗАПРОСИЛ, чтобы клиент вошел через HTTP-аутентификацию и послал заголовки ответа, чтобы инициировать процесс. Возможно, есть авторизации, которые разрешат доступ к ресурсу, возможно, нет, но давайте попробуем и посмотрим, что произойдет.

403 указывает, что ресурс не может быть предоставлен, и для текущего пользователя нет никакого способа решить это через RFC2617 и нет смысла пытаться. Это может быть связано с тем, что известно, что никакого уровня аутентификации недостаточно (например, из-за черного списка IP-адресов), но это может быть связано с тем, что пользователь уже аутентифицирован и не имеет полномочий. Модель RFC2617 является однопользовательской, однопользовательской, поэтому случай, когда у пользователя может быть второй набор учетных данных, которые могут быть авторизованы, может быть проигнорирован. Это не предполагает и не подразумевает, что какая-либо страница входа в систему или другой протокол аутентификации, отличный от RFC2617, может или не может помочь - что находится за пределами стандартов и определений RFC2616.


Изменить: RFC2616 устарел, см. RFC7231 и RFC7235 .

ldrut
источник
7
Так что же нам делать, когда пользователь запрашивает страницу, требующую аутентификации без http? Отправить код статуса 403?
marcovtwout
2
Это ответ, который ответил на мои вопросы о различии.
Патрик
9
Это важно: «если у вас есть свой собственный процесс входа в систему по собственному усмотрению и вы никогда не используете HTTP-аутентификацию, 403 всегда является правильным ответом, а 401 никогда не должен использоваться».
GGG
1
@marcovtwout Отправьте 302 на вашу страницу входа или 403, содержащую тело с информацией, как войти в систему?
Алекс
4
Разве RFC7235 не предоставляет "рулонные собственные" или альтернативные задачи аутентификации? Почему поток входа в мое приложение не может представлять проблему в виде WWW-Authenticateзаголовка? Даже если браузер не поддерживает его, мое приложение React может ...
jchook
127
  + -----------------------
  | РЕСУРС СУЩЕСТВУЕТ? (если приватный, то часто проверяется ПОСЛЕ проверки подлинности)
  + -----------------------
    | |
 НЕТ | В ДА
    v + -----------------------
   404 | ВОЙТИЛ? (аутентифицировано, aka имеет сеанс или JWT cookie)
   или + -----------------------
   401 | |
   403 НЕТ | | ДА
   3xx вв
              401 + -----------------------
       (404 не раскрывать) | МОЖЕТ ЛИ ДОСТУП К РЕСУРСУ (разрешение, разрешение, ...)
              или + -----------------------
             перенаправление | |
             войти НЕТ | | ДА
                               | |
                               ст
                               403 OK 200, перенаправление, ...
                      (или 404: не раскрывать)
                      (или 404: ресурс не существует, если он частный)
                      (или 3xx: перенаправление)

Проверки обычно проводятся в следующем порядке:

  • 404 если ресурс публичный и не существует или перенаправление 3xx
  • В ПРОТИВНОМ СЛУЧАЕ:
  • 401, если не вошел в систему или сеанс истек
  • 403, если у пользователя нет прав доступа к ресурсу (файл, json, ...)
  • 404 если ресурс не существует или не хочет ничего раскрывать, или перенаправление 3xx

НЕСАНКЦИОНИРОВАННО : Код состояния (401), указывающий, что запрос требует аутентификации , обычно это означает, что пользователь должен войти в систему (сеанс). Пользователь / агент неизвестен серверу. Можно повторить с другими учетными данными. ПРИМЕЧАНИЕ: это сбивает с толку, поскольку это должно было быть названо «неаутентифицированным» вместо «неавторизованным». Это также может произойти после входа в систему, если сеанс истек. Особый случай: Может использоваться вместо 404, чтобы избежать выявления наличия или отсутствия ресурса (credits @gingerCodeNinja)

ЗАПРЕЩЕНО : код состояния (403), указывающий, что сервер понял запрос, но отказался его выполнить. Пользователь / агент, известный серверу, но с недостаточными учетными данными . Повторный запрос не будет работать, если учетные данные не изменены, что очень маловероятно за короткий промежуток времени. Особый случай: Может использоваться вместо 404, чтобы избежать выявления наличия или отсутствия ресурса (credits @gingerCodeNinja)

НЕ НАЙДЕН : Код состояния (404), указывающий, что запрошенный ресурс недоступен. Пользователь / агент известен, но сервер ничего не раскрывает о ресурсе, если он не существует. Повтор не сработает. Это специальное использование 404 (например, github).

Как упомянуто @ChrisH, есть несколько вариантов перенаправления 3xx (301, 302, 303, 307 или не перенаправления вообще и использования 401):

Кристоф Русси
источник
Например, я вошел в систему и могу получить доступ к странице, но у меня нет разрешенных разрешений. Какой код статуса вернется?
бартелома
@bookmarker Вход в систему называется аутентификацией, что является первым шагом. Поэтому, если у вас нет разрешения после входа в систему, вы получите 403 Запрещено (недостаточные учетные данные означают, что у вас недостаточно разрешений).
Кристоф Русси
3
Понятное и простое объяснение. Как раз то, что мне нужно.
Эстевес
если пользователь не вошел в систему или не вошел в систему, но не имеет разрешения, а содержимое не существует на месте, иногда вы, вероятно, захотите вернуть 401/403 вместо 404, чтобы не раскрывать то, что есть или нет нет, если пользователь не аутентифицирован и не вошел в систему. Знание того, что что-то существует, может намекнуть на что-то или нарушить NDA. Таким образом, иногда часть 404 этой диаграммы должна быть перемещена в систему вошедших в систему / аутентифицированных.
gingerCodeNinja
1
@MattKocaj обратите внимание, что no revealслучай иногда может быть обнаружен с помощью незначительных временных различий и не должен рассматриваться как функция безопасности, он может просто замедлить действия злоумышленников или немного помочь с конфиденциальностью.
Кристоф Русси
113

Согласно RFC 2616 (HTTP / 1.1) 403 отправляется, когда:

Сервер понял запрос, но отказывается его выполнить. Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться. Если метод запроса не был HEAD и сервер желает сообщить, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте. Если сервер не желает предоставлять эту информацию клиенту, вместо него можно использовать код состояния 404 (не найден).

Другими словами, если клиент МОЖЕТ получить доступ к ресурсу путем аутентификации, следует отправить 401.

Cumbayah
источник
5
И если не ясно, могут ли они получить доступ или нет? Скажите, что у меня есть 3 уровня пользователя - Публичный, Члены и Премиум-пользователи. Предположим, что страница предназначена только для премиум-пользователей. Публичный пользователь, как правило, не проходит проверку подлинности и может входить либо в члены, либо в премиум-члены при входе в систему. Для уровня пользователя-участника 403 может показаться подходящим. Для Премиум-пользователей - 401. Но чем вы обслуживаете публику?
VirtuosiMedia
27
Имхо, это самый точный ответ. это зависит от приложения, но, как правило, если аутентифицированный пользователь не имеет достаточных прав на ресурс, вы можете предоставить способ изменить учетные данные или отправить 401. Я думаю, что 403 лучше всего подходит для контента, который никогда не обслуживается. В asp.net это будет означать файлы web.config * .resx и т. Д., Поскольку независимо от того, какой пользователь входит в систему, эти файлы НИКОГДА не будут обслуживаться, поэтому нет смысла пытаться снова.
Мел
6
+1, но неопределенный +1. Логический вывод состоит в том, что 403 никогда не следует возвращать, так как 401 или 404 будут строго лучшим ответом.
CurtainDog
12
@Mel Я думаю, что файл, к которому клиент не должен обращаться, должен быть 404. Это файл, который является внутренним для системы; внешнее не должно даже знать, что оно существует. Возвращая 403, вы даете клиенту понять, что он существует, и нет необходимости передавать эту информацию хакерам. В спецификации для 403 написаноAn origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
Хуан Мендес,
3
Хотя мне кажется, что это, вероятно, точная интерпретация старого RFC 2616, обратите внимание, что RFC 7231 по-разному определяет семантику 403 и фактически прямо заявляет, что «клиент МОЖЕТ повторить запрос с новыми или другими учетными данными». Таким образом, хотя этот ответ был точным в 2010 году, сегодня он совершенно неверен, потому что значение кода состояния было переписано у нас под ногами. (К сожалению, приложение « Изменения из RFC 2616» не подтверждает это изменение!)
Марк Амери
46

Предполагая , что HTTP аутентификация ( WWW-Authenticate и Authorization заголовков) используется , если аутентификация как другой пользователь будет предоставлять доступ к запрашиваемому ресурсу, а затем 401 Несанкционированные должны быть возвращены.

403 Запрещено используется, когда доступ к ресурсу запрещен для всех или ограничен определенной сетью или разрешен только по SSL, независимо от того, что это не связано с аутентификацией HTTP.

Если HTTP-аутентификация не используется и обслуживает схему аутентификации на основе файлов cookie, что является нормой в настоящее время, то следует вернуть 403 или 404.

Что касается 401, это из RFC 7235 (протокол передачи гипертекста (HTTP / 1.1): аутентификация):

3.1. 401 Несанкционированный

Код состояния 401 (неавторизованный) указывает, что запрос не был применен, поскольку в нем отсутствуют действительные учетные данные аутентификации для целевого ресурса. Исходный сервер ДОЛЖЕН отправить поле заголовка WWW-Authenticate (раздел 4.4), содержащее как минимум один запрос, применимый к целевому ресурсу. Если в запрос включены учетные данные для проверки подлинности, то ответ 401 указывает, что для этих учетных данных было отказано в авторизации., Клиент МОЖЕТ повторить запрос с новым или замененным полем заголовка Авторизация (Раздел 4.1). Если ответ 401 содержит ту же проблему, что и предыдущий ответ, и пользовательский агент уже предпринял попытку аутентификации по крайней мере один раз, тогда пользовательскому агенту СЛЕДУЕТ представить приложенное представление пользователю, поскольку оно обычно содержит соответствующую диагностическую информацию.

Семантика 403 (и 404) со временем изменилась. Это с 1999 года (RFC 2616):

10.4.4 403 Запрещено

Сервер понял запрос, но отказывается его выполнить.
Авторизация не поможет и запрос НЕ ДОЛЖЕН повторяться.
Если метод запроса не был HEAD и сервер желает сообщить,
почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте. Если сервер не желает предоставлять эту информацию клиенту,
вместо него можно использовать код состояния 404 (не найден).

В 2014 RFC 7231 (протокол передачи гипертекста (HTTP / 1.1): семантика и контент) изменил значение 403:

6.5.3. 403 Запрещено

Код состояния 403 (Запрещено) указывает, что сервер понял запрос, но отказывается его авторизовать. Сервер, который хочет обнародовать, почему запрос был запрещен, может описать эту причину в полезной нагрузке ответа (если есть).

Если в запросе были предоставлены учетные данные для проверки подлинности,
сервер считает их недостаточными для предоставления доступа. Клиент
НЕ ДОЛЖЕН автоматически повторять запрос с теми же
учетными данными. Клиент МОЖЕТ повторить запрос с новыми или другими учетными данными. Однако запрос может быть запрещен по причинам,
не связанным с учетными данными.

Исходный сервер, который хочет «скрыть» текущее существование
запрещенного целевого ресурса, МОЖЕТ вместо этого ответить кодом состояния
404 (Не найдено).

Таким образом, 403 (или 404) теперь может означать что угодно. Предоставление новых учетных данных может помочь ... или не поможет.

Я полагаю, что причина, по которой это изменилось, заключается в том, что RFC 2616 предполагал, что аутентификация HTTP будет использоваться, когда на практике современные веб-приложения создают собственные схемы аутентификации с использованием, например, форм и файлов cookie.

Эрван Легран
источник
2
Это интересно. Основываясь на RFC 7231 и RFC 7235, я не вижу явного различия между 401 и 403
Брайан
2
403 означает «Я знаю тебя, но ты не видишь этот ресурс». Там нет причин для путаницы.
Майкл Блэкберн
«Если запрос включал учетные данные аутентификации, то ответ 401 указывает, что авторизация была отклонена для этих учетных данных. Клиент МОЖЕТ повторить запрос с новым или замененным полем заголовка авторизации (раздел 4.1)». Однако тогда «4.2. Поле заголовка« Авторизация »позволяет агенту пользователя аутентифицировать себя на сервере происхождения». Похоже, в RFC7235 они используют термин «авторизация», как это было «аутентификация». В этом случае может показаться, что аутентифицированный, но не авторизованный пользователь не должен получить 401, а скорее 403
arcuri82
29

Это более старый вопрос, но один вариант, который так и не был поставлен, состоял в том, чтобы вернуть 404. С точки зрения безопасности, голос с наибольшим количеством голосов страдает от потенциальной уязвимости утечки информации . Скажем, например, что рассматриваемая защищенная веб-страница является страницей системного администратора или, что более часто, является записью в системе, к которой у пользователя нет доступа. В идеале вы бы не хотели, чтобы злоумышленник даже знал, что там есть страница / запись, не говоря уже о том, что у него нет доступа. Когда я создаю что-то подобное, я пытаюсь записать неавторизованные / неавторизованные запросы во внутренний журнал, но возвращаю 404.

OWASP содержит дополнительную информацию о том, как злоумышленник может использовать этот тип информации как часть атаки.

Патрик Уайт
источник
3
Использование 404 было упомянуто в предыдущих ответах. Вы на пути к утечке информации, и это должно быть важным фактором для любого, кто использует собственную схему аутентификации / авторизации. +1 за упоминание OWASP.
Дейв Уоттс
По иронии судьбы ссылка OWASP теперь идет на страницу 404. Я нашел что-то похожее (я думаю) на owasp.org/index.php/…
anned20
Спасибо за заголовки, я обновил это!
Патрик Уайт
Зависит от API и способа предоставления доступа. Но «утечка» не проблема, если он возвращает 401 для имени пользователя / пароля, это точно так же, как для веб-формы, конечно?
Джеймс
26
  • 401 Несанкционированный : я не знаю, кто вы. Это ошибка аутентификации.
  • 403 Запрещено : я знаю, кто вы, но у вас нет разрешения на доступ к этому ресурсу. Это ошибка авторизации.
Акшай Мисал
источник
Не уверен, что именно «всегда» означает, что отправитель был неизвестен. Просто то, что они просили, не было разрешено.
Джеймс
22

Этот вопрос был задан некоторое время назад, но мышление людей движется дальше.

Раздел 6.5.3 в этом проекте (автор Fielding и Reschke) дает код состояния 403, немного отличающийся от того, который задокументирован в RFC 2616 .

Он отражает то, что происходит в схемах аутентификации и авторизации, используемых рядом популярных веб-серверов и сред.

Я подчеркнул бит, который я считаю наиболее заметным.

6.5.3. 403 Запрещено

Код состояния 403 (Запрещено) указывает, что сервер понял запрос, но отказывается его авторизовать. Сервер, который хочет обнародовать, почему запрос был запрещен, может описать эту причину в полезной нагрузке ответа (если есть).

Если в запросе были предоставлены учетные данные для проверки подлинности, сервер считает их недостаточными для предоставления доступа. Клиент не должен повторять запрос с теми же учетными данными. Клиент МОЖЕТ повторить запрос с новыми или другими учетными данными. Однако запрос может быть запрещен по причинам, не связанным с учетными данными.

Исходный сервер, который хочет «скрыть» текущее существование запрещенного целевого ресурса, МОЖЕТ вместо этого ответить кодом состояния 404 (Не найдено).

Какое бы соглашение вы не использовали, важно обеспечить единообразие для вашего сайта / API.

Дейв Уоттс
источник
2
Проект был одобрен и в настоящее время RFC 7231.
Вебьорн Льоса,
13

TL; DR

  • 401: отказ, связанный с аутентификацией
  • 403: отказ, который не имеет ничего общего с аутентификацией

Практические примеры

Если Apache требует аутентификации (через .htaccess), и вы нажмете Cancel, он ответит401 Authorization Required

Если nginx находит файл, но не имеет прав доступа (пользователь / группа) для чтения / доступа к нему, он ответит403 Forbidden

RFC (2616 Раздел 10)

401 Несанкционированный (10.4.2)

Значение 1: необходимо подтвердить подлинность

Запрос требует аутентификации пользователя. ...

Значение 2: аутентификация недостаточна

... Если в запрос уже включены учетные данные авторизации, то ответ 401 указывает, что в авторизации было отказано для этих учетных данных. ...

403 Запрещено (10.4.4)

Значение: не связано с аутентификацией

... авторизация не поможет ...

Больше деталей:

  • Сервер понял запрос, но отказывается его выполнить.

  • СЛЕДУЕТ описать причину отказа в организации

  • Вместо этого можно использовать код состояния 404 (не найден)

    (Если сервер хочет сохранить эту информацию от клиента)

левит
источник
11

они не вошли в систему или не принадлежат к соответствующей группе пользователей

Вы изложили два разных случая; у каждого случая должен быть свой ответ:

  1. Если они вообще не вошли в систему, вы должны вернуть 401 Unauthorized
  2. Если они вошли в систему, но не принадлежат к соответствующей группе пользователей, вы должны вернуть 403 Запрещено

Примечание к RFC на основе комментариев, полученных к этому ответу:

Если пользователь не вошел в систему, он не прошел проверку подлинности, HTTP-эквивалент которого равен 401, и в RFC вводит в заблуждение, называя его Несанкционированным. Как указано в разделе 10.4.2 для 401 Unauthorized :

«Запрос требует аутентификации пользователя ».

Если вы не прошли проверку подлинности, 401 является правильным ответом. Однако, если вы не авторизованы, в семантически правильном смысле 403 - это правильный ответ.

Зайд Масуд
источник
5
Это не правильно. Обратитесь к RFC и ответу @ Cumbayah.
Давид Р.
7
@DavideR. RFC использует аутентификацию и авторизацию взаимозаменяемо. Я считаю, что это имеет больше смысла при чтении со значением аутентификации .
Заид Масуд
Этот ответ обратный. Несанкционированный - это не то же самое, что Несанкционированный. @DavideR прав. Аутентификация и авторизация НЕ взаимозаменяемы
BozoJoe
2
2616 должен быть сожжен. Несколько новых RFC гораздо яснее, что необходимо различать «я тебя не знаю» и «я тебя знаю, но ты не можешь получить к этому доступ». Там нет нет законных оснований , чтобы признать существование ресурса , который никогда не будет выполнен (или не выполняется через HTTP), который является то , что 403-truthers предлагает.
Майкл Блэкберн
6

Вот эти значения:

401 : пользователь не (правильно) аутентифицирован, ресурс / страница требуют аутентификации

403. Пользователь прошел проверку подлинности, но его роль или разрешения не позволяют получить доступ к запрашиваемому ресурсу, например, пользователь не является администратором, а запрашиваемая страница предназначена для администраторов.

Лука С.
источник
Это отличный ответ TLDR на этот вопрос.
Куша
5

Это проще в моей голове, чем где-либо здесь, поэтому:

401: вам нужна базовая аутентификация HTTP, чтобы увидеть это.

403: Вы не можете видеть это, и базовая аутентификация HTTP не поможет.

Если пользователю просто необходимо войти в систему, используя стандартную HTML-форму входа в систему на вашем сайте, 401 не подойдет, потому что она специфична для базовой аутентификации HTTP.

Я не рекомендую использовать 403 для запрета доступа к таким вещам /includes, потому что, что касается Интернета, эти ресурсы вообще не существуют и поэтому должны 404.

Это оставляет 403 как «Вы должны войти в систему».

Другими словами, 403 означает «этот ресурс требует некоторой формы аутентификации, отличной от базовой аутентификации HTTP».

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

Владимир Корнеа
источник
5

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

Вот некоторые случаи в соответствии с этой логикой, когда ошибка будет возвращена из аутентификации или авторизации, с выделением важных фраз.

  • Ресурс требует аутентификации, но учетные данные не указаны .

401 : клиент должен указать учетные данные.

  • Указанные учетные данные имеют недопустимый формат .

400 : это ни 401, ни 403, поскольку синтаксические ошибки всегда должны возвращать 400.

  • Указанные учетные данные ссылаются на пользователя, который не существует .

401 : клиент должен указать действительные учетные данные.

  • Указанные полномочия являются недействительными , но указать действительный пользователь (или не указать пользователя , если указанный пользователем не требуется).

401 : Опять же, клиент должен указать действительные учетные данные.

  • Указанные полномочия были истекли .

401 : Это практически то же самое, что и неверные учетные данные в целом, поэтому клиент должен указать действительные учетные данные.

  • Указанные учетные данные полностью действительны, но их недостаточно для конкретного ресурса , хотя вполне возможно, что учетные данные с более широкими правами могут.

403. Указание допустимых учетных данных не предоставит доступ к ресурсу, поскольку текущие учетные данные уже действительны, но только не имеют разрешения.

  • Конкретный ресурс является недоступным независимо от учетных данных.

403. Это не зависит от учетных данных, поэтому указание действительных учетных данных не может помочь.

  • Указанные полномочия являются полностью действительными , но конкретный клиент будет заблокирован от их использования.

403. Если клиент заблокирован, указание новых учетных данных ничего не изменит.

Грант Гричан
источник
4

На английском:

401

Вам потенциально разрешен доступ, но по какой-то причине по этому запросу вам было отказано. Например, плохой пароль? Попробуйте еще раз, с правильным запросом вы получите успешный ответ.

403

Тебе никогда не разрешено. Вашего имени нет в списке, вы никогда не будете входить, уходите, не отправляйте запрос на повторную попытку, вам всегда будет отказано. Уходи.

Джеймс
источник
1

Учитывая последние RFC по этому вопросу ( 7231 и 7235 ), сценарий использования выглядит вполне ясным (курсив добавлен):

  • 401 для неаутентифицированных («не хватает действительной аутентификации»); то есть «я не знаю, кто вы, или я не верю, что вы тот, кем вы говорите».

401 Несанкционированный

Код состояния 401 (неавторизованный) указывает, что запрос не был применен, поскольку в нем отсутствуют действительные учетные данные аутентификации для целевого ресурса. Сервер, генерирующий ответ 401, ДОЛЖЕН отправить поле заголовка WWW-Authenticate (раздел 4.1), содержащее, по крайней мере, один запрос, применимый к целевому ресурсу.

Если в запрос включены учетные данные для проверки подлинности, то ответ 401 указывает, что для этих учетных данных было отказано в авторизации. Пользовательский агент МОЖЕТ повторить запрос с новым или замененным полем заголовка Авторизация (Раздел 4.2). Если ответ 401 содержит ту же проблему, что и предыдущий ответ, и пользовательский агент уже предпринял попытку аутентификации, по крайней мере, один раз, тогда пользовательский агент ДОЛЖЕН представить приложенное представление пользователю, поскольку он обычно содержит соответствующую диагностическую информацию.

  • 403 для неавторизованных («отказывает в авторизации»); т.е. «Я знаю, кто вы, но у вас нет разрешения на доступ к этому ресурсу».

403 Запрещено

Код состояния 403 (Запрещено) указывает, что сервер понял запрос, но отказывается его авторизовать . Сервер, который хочет обнародовать, почему запрос был запрещен, может описать эту причину в полезной нагрузке ответа (если есть).

Если в запросе были предоставлены учетные данные для проверки подлинности, сервер считает их недостаточными для предоставления доступа. Клиент НЕ ДОЛЖЕН автоматически повторять запрос с теми же учетными данными. Клиент МОЖЕТ повторить запрос с новыми или другими учетными данными. Однако запрос может быть запрещен по причинам, не связанным с учетными данными.

Исходный сервер, который хочет «скрыть» текущее существование запрещенного целевого ресурса, МОЖЕТ вместо этого ответить кодом состояния 404 (Не найдено).

cjbarth
источник
2
-1; эти отрывки уже были процитированы в других ответах здесь, и ваш не добавляет ничего нового. Я бы сказал, что явно не ясно, что это за различие; Вы суммируете два кода как «отсутствует действительная аутентификация» и «отказывается авторизоваться», но я не могу представить себе ситуацию, в которой одно из этих кратких описаний могло бы применяться, когда другое не могло бы быть истолковано как применимое.
Марк Амери
Здесь есть много ответов, которые охватывают многие RFC и отредактированы и обновлены, загрязняя воды. Я включил ссылку, чтобы объяснить, что authenticatedесть и что authorizedесть, и остановил все устаревшие RFC, чтобы приложение было понятным.
cjbarth
Ваше редактирование разъясняет вашу интерпретацию двух кодов, которая, кажется, соответствует интерпретации многих других людей. Тем не менее, я лично считаю, что интерпретация имеет мало смысла. Использование фразы « Если были предоставлены учетные данные для аутентификации» в описании 403 подразумевает, что 403 может быть подходящим, даже если учетные данные не были предоставлены - то есть случай «неаутентифицированный». Между тем, для меня наиболее естественная интерпретация фразы «для целевого ресурса» , включенной в описание 401, состоит в том, что 401 может использоваться для пользователя, который аутентифицирован, но не авторизован.
Марк Амери
-6

В случае 401 против 403, на это много раз отвечали. По сути, это дебаты «среды HTTP-запросов», а не «приложений».

Похоже, что возникает вопрос о проблеме «подкатить-под-именем-входа» (приложение).

В этом случае просто не войти в систему недостаточно для отправки 401 или 403, если только вы не используете HTTP Auth против страницы входа (не привязанной к настройке HTTP Auth). Похоже, вы ищете «201 Created», с присутствующим на экране скрининга входа (вместо запрошенного ресурса) для доступа к файлу на уровне приложения. Это говорит:

«Я слышал, это здесь, но попробуйте вместо этого (вы не можете видеть это)»

Шон
источник
Что именно создается?
Грант Гричан