Для веб-сторінки, яка існує, але для якої користувач не має достатніх привілеїв (вони не ввійшли або не належать до належної групи користувачів), яким правильним буде відповідь HTTP?

401 Unauthorized?
403 Forbidden?
Щось ще?

Те, що я читав на кожному з цих пір, не дуже зрозуміло щодо різниці між ними. Які випадки використання підходять для кожної відповіді?

Чітке пояснення від Даніеля Ірвіна :

Існує проблема із 401 Несанкціонованим кодом статусу HTTP для помилок аутентифікації. І це просто так: це для автентифікації, а не для авторизації. Отримавши відповідь 401, сервер говорить вам: "Ви не пройшли автентифікацію - або не пройшли автентифікацію, або автентифіковано неправильно - але, будь ласка, повторно підтвердіть і повторіть спробу". Щоб допомогти вам, він завжди буде містити заголовк WWW-Authenticate, який описує спосіб автентифікації.

Це відповідь, яку, як правило, повертає ваш веб-сервер, а не ваш веб-додаток.

Це теж щось дуже тимчасове; сервер просить спробувати ще раз.

Отже, для авторизації я використовую 403 Заборонену відповідь. Він постійний, він пов'язаний з моєю логікою застосування, і це конкретніша відповідь, ніж 401.

Отримавши відповідь 403, сервер сказав вам: “Пробач. Я знаю, хто ви - я вважаю, ким ви кажете, але ви просто не маєте дозволу на доступ до цього ресурсу. Можливо, якщо ви добре запитаєте системного адміністратора, ви отримаєте дозвіл. Але, будь ласка, не турбуйте мене знову, поки не зміниться ваше становище ».

Підсумовуючи, 401 Несанкціоновану відповідь слід використовувати для відсутньої або поганої автентифікації, а 403 Заборонену відповідь слід використовувати після цього, коли користувач має автентифікацію, але не має права виконувати запитувані операції на даному ресурсі.

Ще один приємний зображальний формат того, як слід використовувати коди статусу http.

Див. RFC2616 :

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

Якщо запит вже включав облікові дані авторизації, відповідь 401 вказує на те, що авторизація відхилена для цих даних.

403 Заборонено:

Сервер зрозумів запит, але відмовляється його виконувати.

Оновлення

З вашого випадку використання виходить, що користувач не має автентифікації. Я б повернувся 401.

Редагувати: RFC2616 застаріло, див. RFC7231 та RFC7235 .

Щось інших відповідей бракує, це те, що слід розуміти, що аутентифікація та авторизація в контексті RFC 2616 посилається ТІЛЬКИ на протокол автентифікації HTTP RFC 2617. Аутентифікація за схемами поза RFC2617 не підтримується в кодах статусу HTTP і не враховується при вирішенні питання про використання 401 чи 403.

Короткі та термінові

Несанкціонований вказує на те, що клієнт не має аутентифікації RFC2617 і сервер ініціює процес аутентифікації. Заборонено вказує або на те, що клієнт має аутентифікацію RFC2617 і не має авторизації, або що сервер не підтримує RFC2617 для запитуваного ресурсу.

Це означає, що якщо у вас є власний власний процес входу, і ви ніколи не використовуєте HTTP-аутентифікацію, 403 - це завжди відповідна відповідь і 401 ніколи не слід використовувати.

Детально і поглиблено

З RFC2616

10.4.2 401 Несанкціоновано

У запиті потрібна автентифікація користувача. Відповідь ОБОВ'ЯЗКОВО включатиме поле заголовка WWW-Authenticate (розділ 14.47), що містить виклик, застосовний до запитуваного ресурсу. Клієнт МОЖЕ повторити запит у відповідному полі заголовка Авторизація (розділ 14.8).

і

10.4.4 403 Заборонено Сервер зрозумів запит, але відмовляється його виконувати. Авторизація не допоможе, і запит НЕ повинен повторюватися.

Перше, що потрібно пам’ятати, - це те, що «Автентифікація» та «Авторизація» в контексті цього документа конкретно посилаються на протоколи автентифікації HTTP від ​​RFC 2617. Вони не посилаються на будь-які створені вами власні протоколи аутентифікації, які ви могли створити використовуючи сторінки входу і т.д. Я буду використовувати "login" для позначення автентифікації та авторизації іншими методами, ніж RFC2617

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

401 вказує, що ресурс не може бути наданий, але сервер ЗАПИТВАЄ, щоб клієнт увійшов через HTTP-аутентифікацію та надіслав заголовки відповідей, щоб ініціювати процес. Можливо, є авторизація, яка дозволить отримати доступ до ресурсу, можливо, їх немає, але давайте спробуємо і подивимося, що відбувається.

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

Редагувати: RFC2616 застаріло, див. RFC7231 та RFC7235 .

  + -----------------------
  | РЕСУРС Є? (якщо приватне, його часто перевіряють ПІСЛЯ авторизації)
  + -----------------------
    | |
 НІ | v ТАК
    v + -----------------------
   404 | ЛІГУВАННЯ? (автентифіковано, він також має файли cookie сеансу або JWT)
   або + -----------------------
   401 | |
   403 НЕТ | | ТАК
   3xx vv
              401 + -----------------------
       (404 немає виявлення) | МОЖЕТЕ ДОСТУПНІ РЕСУРСИ? (дозвіл, уповноважений, ...)
              або + -----------------------
             перенаправлення | |
             для входу НЕ | | ТАК
                               | |
                               vv
                               403 ОК 200, переадресація, ...
                      (або 404: немає виявлення)
                      (або 404: ресурс не існує, якщо приватний)
                      (або 3xx: перенаправлення)

Перевірки зазвичай робляться в такому порядку:

• 404, якщо ресурс є загальнодоступним і не існує, або перенаправлення 3xx
• ІНШИЙ:
• 401, якщо не ввійшли в систему або сеанс минув
• 403, якщо користувач не має дозволу на доступ до ресурсу (файл, json, ...)
• 404, якщо ресурс не існує або не бажає нічого розкривати, або перенаправлення 3xx

НЕУТОРОВАНО : Код стану (401), який вказує на те, що для запиту потрібна автентифікація , зазвичай це означає, що користувачеві потрібно ввійти (сеанс). Користувач / агент невідомий сервером. Можна повторити з іншими обліковими записами. ПРИМІТКА. Це заплутано, оскільки це повинно було бути названо "неаутентифікованим" замість "несанкціонованим". Це також може відбутися після входу, якщо сеанс минув. Особливий випадок: може використовуватися замість 404, щоб уникнути виявлення або відсутності ресурсу (кредити @gingerCodeNinja)

ЗАБОРОНЕНО : Код стану (403), який вказує на те, що сервер зрозумів запит, але відмовився його виконати. Користувач / агент, відомий сервером, але не має достатньої кількості даних . Повторний запит не спрацює, якщо не змінити облікові дані, що дуже малоймовірно за короткий проміжок часу. Особливий випадок: може використовуватися замість 404, щоб уникнути виявлення або відсутності ресурсу (кредити @gingerCodeNinja)

NOT FOUND : Код стану (404), який вказує на те, що запитуваний ресурс недоступний. Користувач / агент, відомий, але сервер нічого не розкриє про ресурс, немовби його не було. Повторення не вийде. Це особливе використання 404 (github робить це, наприклад).

Як зазначає @ChrisH, є кілька варіантів перенаправлення 3xx (301, 302, 303, 307 або взагалі не переадресація та використання 401):

• Різниця між кодами переадресації HTTP
• Як довго браузери кешують HTTP 301?
• Що таке правильний код статусу HTTP під час переадресації на сторінку входу?
• Яка різниця між перенаправленням 302 та 307?

Згідно з RFC 2616 (HTTP / 1.1) 403 надсилається, коли:

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

Іншими словами, якщо клієнт МОЖЕ отримати доступ до ресурсу шляхом автентифікації, слід надіслати 401.

Припускаючи , що 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.

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

У OWASP є додаткова інформація про те, як зловмисник може використовувати цей тип інформації як частину нападу.

• 401 Несанкціонований : я не знаю, хто ви. Це помилка аутентифікації.
• 403 Заборонено : Я знаю, хто ви є, але у вас немає дозволу на доступ до цього ресурсу. Це помилка авторизації.

Це питання задавали деякий час тому, але мислення людей рухається далі.

Розділ 6.5.3 цього проекту (автор Філдінг та Решке) надає код статусу 403 дещо інше значення, ніж це зафіксовано в RFC 2616 .

Він відображає те, що відбувається в схемах аутентифікації та авторизації, використовуваних низкою популярних веб-серверів та фреймворків.

Я наголосив на тому, що я вважаю найбільш яскравим.

6.5.3. 403 Заборонено

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

Якщо в запиті були надані облікові дані автентифікації, сервер вважає їх недостатніми для надання доступу. Клієнт НЕ повинен повторювати запит з однаковими обліковими записами. Клієнт МОЖЕ повторити запит з новими або різними обліковими записами. Однак запит може бути заборонено з причин, не пов'язаних з обліковими даними.

Сервер походження, який бажає "приховати" поточне існування забороненого цільового ресурсу, МОЖЕ натомість відповісти кодом статусу 404 (Не знайдено).

Яку б умову ви не використовували, важливим є забезпечення рівномірності на вашому веб-сайті / API.

TL; DR

• 401: Відмова, пов'язана з автентифікацією
• 403: Відмова, яка НІЧОГО не стосується автентифікації

Практичні приклади

Якщо apache вимагає автентифікації (через .htaccess), і ви натиснете Cancel, він відповість a401 Authorization Required

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

RFC (2616 Розділ 10)

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

Значення 1: Необхідно пройти автентифікацію

У запиті потрібна автентифікація користувача. ...

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

... Якщо запит вже включав облікові дані авторизації, відповідь 401 вказує на те, що авторизація відхилена для цих даних. ...

403 Заборонено (10.4.4)

Значення: Не пов'язане з аутентифікацією

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

Детальніше:

• Сервер зрозумів запит, але відмовляється його виконувати.

• ДОТРІБНО описати причину відмови в організації

• Натомість можна використовувати код статусу 404 (Не знайдено)

  (Якщо сервер хоче зберегти цю інформацію від клієнта)

вони не зареєстровані або не належать до належної групи користувачів

Ви заявили два різні випадки; кожен випадок повинен мати різну відповідь:

1. Якщо вони взагалі не ввійшли в систему, ви повинні повернути 401 Несанкціоновано
2. Якщо вони зареєстровані, але не належать до належної групи користувачів, вам слід повернути 403 Заборонено

Зауважте на RFC на основі коментарів, отриманих до цієї відповіді:

Якщо користувач не ввійшов до системи, він не має автентифікації, HTTP-еквівалент якого 401 і вводять в оману Несанкціонований в RFC. Як зазначено в розділі 10.4.2 для 401 Несанкціонованого :

"У запиті потрібна автентифікація користувача ."

Якщо ви не автентифіковані, 401 - це правильна відповідь. Однак якщо ви несанкціоновані, у семантично правильному розумінні 403 - це правильна відповідь.

Це значення:

401 : Користувач не (правильно) підтверджено автентифікацію, ресурс / сторінка вимагає автентифікації

403 : Автентифікація користувача, але його роль або дозволи не дозволяють отримати доступ до запитуваного ресурсу, наприклад, користувач не є адміністратором, а сторінка, яку запитують, призначена для адміністраторів

Це в моїй голові простіше, ніж де-небудь тут, так що:

401: Вам потрібен основний протокол HTTP, щоб побачити це.

403: Ви цього не можете бачити, і основний протокол HTTP не допоможе.

Якщо користувачеві потрібно просто увійти в систему за допомогою стандартної форми для входу на ваш сайт, 401 було б не доцільно, оскільки це специфічно для базового авторизації HTTP.

Я не рекомендую використовувати 403, щоб заборонити доступ до таких речей /includes, оскільки що стосується Інтернету, то ці ресурси взагалі не існують і тому повинні 404.

Це залишає 403 як "вам потрібно увійти".

Іншими словами, 403 означає, що "цей ресурс вимагає певної форми аутентифікації, відмінного від базового авторизації HTTP".

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

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

Ось деякі випадки за цією логікою, коли помилка буде повернута під час автентифікації або авторизації, а важливі фрази виділені жирним шрифтом.

• Для ресурсу потрібна автентифікація, але не було вказано облікових даних .

401 : Клієнт повинен вказати облікові дані.

• Зазначені облікові дані мають недійсний формат .

400 : Це ні 401, ні 403, оскільки синтаксичні помилки завжди повинні повертати 400.

• Вказані облікові дані посилаються на користувача, якого не існує .

401 : Клієнт повинен вказати дійсні облікові дані.

• Зазначені повноваження є недійсними , але вказати дійсний користувач (або не вказати користувача , якщо зазначений користувачем не потрібно).

401 : Знову ж, клієнт повинен вказати дійсні облікові дані.

• Зазначені повноваження були минули .

401 : Це практично те саме, що недійсні облікові дані взагалі, тому клієнт повинен вказати дійсні облікові дані.

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

403 : Вказання дійсних облікових даних не дозволить отримати доступ до ресурсу, оскільки поточні облікові дані вже дійсні, але лише не мають дозволу.

• Конкретний ресурс є недоступним незалежно від облікових даних.

403 : Це незалежно від облікових даних, тому визначення дійсних даних не може допомогти.

• Зазначені повноваження є повністю дійсними , але конкретний клієнт буде заблокований від їх використання.

403 : Якщо клієнт заблокований, введення нових облікових даних нічого не зробить.

Англійською:

401

Вам потенційно дозволений доступ, але чомусь у цьому запиті вам відмовили. Такий як неправильний пароль? Спробуйте ще раз, при правильному запиті ви отримаєте відповідь про успіх.

403

Вам ніколи не дозволено. Вашого імені немає в списку, ви ніколи не ввійдете, підете, не надсилайте запит на повторну спробу, відмовлятимуть завжди. Йди геть.

Враховуючи останні RFC з цього питання ( 7231 та 7235 ), випадок використання видається досить зрозумілим (курсив додано):

• 401 призначений для неаутентифікованих ("не має дійсної автентифікації"); тобто "Я не знаю, хто ти, або я не вірю, що ти такий, про кого ти кажеш".

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

Код стану 401 (Несанкціонований) вказує на те, що запит не застосовувався, оскільки йому не вистачає дійсної автентифікації облікові дані для цільового ресурсу. Сервер, що генерує відповідь 401, ПОВИНЕН надіслати поле заголовка WWW-Authenticate (Розділ 4.1), що містить принаймні один виклик, застосовний до цільового ресурсу.

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

• 403 - для несанкціонованих («відмовляє в авторизації»); тобто "Я знаю, хто ви є, але у вас немає дозволу на доступ до цього ресурсу".

403 Заборонено

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

Якщо в запиті були надані облікові дані автентифікації, сервер вважає їх недостатніми для надання доступу. Клієнт НЕ повинен автоматично повторювати запит з тими ж даними. Клієнт МОЖЕ повторити запит з новими або різними обліковими записами. Однак запит може бути заборонено з причин, не пов'язаних з обліковими даними.

Сервер походження, який бажає "приховати" поточне існування забороненого цільового ресурсу, МОЖЕ натомість відповісти кодом статусу 404 (Не знайдено).

У випадку 401 проти 403 на це відповіли багато разів. Це, по суті, дискусія "середовище запиту HTTP", а не дебат "застосунку".

Здається, виникає запитання щодо питання про власну реєстрацію (додаток).

У цьому випадку просто не ввійти в систему недостатньо для надсилання 401 або 403, якщо ви не використовуєте HTTP Auth vs сторінку входу (не прив’язану до встановлення HTTP Auth). Це здається, що ви можете шукати "201 Створено", з наявним екраном для входу в рулон (замість запитуваного ресурсу) для доступу до файлу на рівні програми. Це говорить:

"Я чув вас, це тут, але спробуйте це замість цього (вам не дозволяється бачити це")