Zobacz RFC2616 :

401 Nieautoryzowano:

Jeśli żądanie zawierało już poświadczenia autoryzacji, odpowiedź 401 wskazuje, że autoryzacja została odrzucona dla tych poświadczeń.

403 Zakazane:

Serwer zrozumiał żądanie, ale odmawia jego spełnienia.

Update

Z twojego przypadku użycia wynika, że użytkownik nie jest uwierzytelniony. I would return 401.

Edit: RFC2616 jest przestarzały, zobacz RFC7231 i RFC7235 .

Czegoś brakuje w innych odpowiedziach jest to, że należy rozumieć, że uwierzytelnianie i autoryzacja w kontekście RFC 2616 odnosi się tylko do protokołu uwierzytelniania HTTP RFC 2617. Uwierzytelnianie przez Schematy spoza RFC2617 nie jest obsługiwane w kodach statusu HTTP i nie jest brane pod uwagę przy podejmowaniu decyzji o użyciu 401 lub 403..

Krótko i zwięźle

Nieautoryzowane oznacza, że Klient nie jest uwierzytelniony w RFC2617, a serwer inicjuje proces uwierzytelniania. Zabronione oznacza, że klient jest uwierzytelniony w RFC2617 i nie ma autoryzacji lub że serwer nie obsługuje RFC2617 dla żądanego zasobu.

Oznacza to, że jeśli masz własny proces logowania i nigdy nie używasz uwierzytelniania HTTP, 403 jest zawsze właściwą odpowiedzią, a 401 nigdy nie powinno być używane.

Szczegółowe i dogłębne

Z RFC2616

10.4.2 401

Prośba wymaga uwierzytelnienia użytkownika. Odpowiedź musi zawierać pole nagłówka WWW-Authenticate (sekcja 14.47) zawierające wyzwanie mające zastosowanie do żądanego zasobu. Klient może powtórzyć żądanie za pomocą odpowiedniego pola nagłówka autoryzacji(sekcja 14.8).

I

10.4.4 403 Serwer zrozumiał żądanie, ale odmawia jego spełnienia. Autoryzacja nie pomoże i żądanie nie powinno być powtarzane.

Pierwsza rzecz do należy pamiętać, że "uwierzytelnianie" i "autoryzacja" w kontekście tego dokumentu odnoszą się konkretnie do protokołów uwierzytelniania HTTP z RFC 2617. Nie odnoszą się one do żadnych własnych protokołów uwierzytelniania utworzonych za pomocą stron logowania itp. Użyję "login", aby odnosić się do uwierzytelniania i autoryzacji metodami innymi niż RFC2617

Więc prawdziwą różnicą nie jest to, czym jest problem, a nawet czy istnieje rozwiązanie. Różnica polega na tym, czego oczekuje serwer klient do następnego.

401 wskazuje, że zasób nie może być dostarczony, ale serwer żąda, aby Klient zalogował się za pomocą uwierzytelniania HTTP i wysłał nagłówki odpowiedzi, aby zainicjować proces. Być może istnieją autoryzacje, które pozwolą na dostęp do zasobu, być może nie, ale spróbujmy i zobaczmy, co się stanie.

403 oznacza, że zasób nie może być dostarczony i nie ma, dla bieżącego użytkownika, sposobu, aby rozwiązać to za pomocą RFC2617 i nie ma sensu próbować. Może to być spowodowane tym, że wiadomo, że żaden poziom uwierzytelniania nie jest wystarczający (na przykład z powodu czarnej listy IP), ale może to być spowodowane tym, że użytkownik jest już uwierzytelniony i nie ma uprawnień. Model RFC2617 jest jednym użytkownikiem, jednym poświadczeniem, więc przypadek, w którym użytkownik może mieć drugi zestaw poświadczeń, które mogą być autoryzowane, może zostać zignorowany. Nie sugeruje ani nie sugeruje, że jakiś rodzaj strony logowania lub innego protokołu uwierzytelniania nie-RFC2617 może lub może nie pomaga - to jest poza standardami i definicją RFC2616.

Edit: RFC2616 jest przestarzały, zobacz RFC7231 I RFC7235 .

Zgodnie z RFC 2616 (HTTP/1.1) 403 jest wysyłany, gdy:

Serwer zrozumiał żądanie, ale odmawia jego spełnienia. Autoryzacja nie pomoże i żądanie nie powinno być powtarzane. Jeżeli metoda żądania nie została zrealizowana, a serwer chce podać do publicznej wiadomości, Dlaczego żądanie nie zostało zrealizowane, powinien opisać przyczynę odmowy w podmiocie. Jeśli serwer nie chce udostępniać tych informacji klientowi, kod statusu 404 (Nie Znalezione) mogą być używane zamiast

Innymi słowy, jeśli klient może uzyskać dostęp do zasobu poprzez uwierzytelnienie, należy wysłać 401.

   GET, resource exists ?
    |      |
 NO |      | YES
    v      v
   404     Is authenticated (logged-in) ?
             |              |
          NO |              | YES
             v              v
             401            Can access resource (has permissions) ?
           (or: 404)        |            |
           or 301        NO |            | YES
           redirect         v            v
           to login        403           OK 200, 301, ...

Kontrole są zwykle wykonywane w tej kolejności:

• 401 jeÅ›li nie jesteÅ› zalogowany lub sesja wygasÅ‚a
• 403 jeÅ›li użytkownik nie ma uprawnieÅ„ dostÄ™pu do zasobu
• 404 jeÅ›li zasób nie istnieje

Nieautoryzowane : kod stanu (401) wskazujący, że żądanie wymaga uwierzytelnienia , zwykle oznacza to, że użytkownik musi być zalogowany (sesja). Użytkownik / agent Nieznany przez serwer. Może powtarzać z innymi poświadczeniami. Uwaga: jest to mylące, ponieważ powinien być nazwany "nieautoryzowany" zamiast "nieautoryzowany". Może to również zakończyć się niepowodzeniem, jeśli sesja wygasła.

FORBIDDEN: kod stanu (403) wskazujący, że serwer zrozumiał żądanie, ale odmówił jego spełnienia. Użytkownik / agent znany przez serwer, ale ma niewystarczające poświadczenia. Powtarzanie żądania nie zadziała, chyba że dane uwierzytelniające ulegną zmianie, co jest bardzo mało prawdopodobne w krótkim czasie.

NOT FOUND : Status code (404) zasób jest niedostępny. Użytkownik / agent znany, ale serwer nie ujawni niczego o zasobie, robi tak, jakby nie istniał. Powtarzanie nie zadziała. Jest to specjalne użycie 404(robi to na przykład github).

Jeśli uwierzytelnienie jako inny użytkownik przyznałoby dostęp do żądanego zasobu, to 401 Nieautoryzowany powinien zostać zwrócony. 403 Forbidden jest najczęściej używany, gdy dostęp do zasobu jest zabroniony dla wszystkich lub ograniczony do danej sieci lub dozwolony tylko przez SSL, niezależnie od tego, o ile nie jest związany z uwierzytelnianiem.

From RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1): Authentication):

3.1. 401 Nieautoryzowano

Status 401 (Nieautoryzowany) kod wskazuje, że wniosek ma nie został zastosowany, ponieważ nie ma ważnych poświadczeń uwierzytelniania dla zasobu docelowego. Serwer origin musi wysłać WWW - pole nagłówka Authenticate (sekcja 4.4) zawierające co najmniej jeden wyzwanie mające zastosowanie do zasobu docelowego. Jeśli wniosek dołączone poświadczenia uwierzytelniania, a następnie odpowiedź 401 wskazuje, że odmówiono pozwolenia na te credentials . Klient może powtórzyć żądanie z nowym lub zastąpiono pole nagłówka autoryzacji(sekcja 4.1). Jeśli 401 odpowiedź Zawiera to samo wyzwanie Co odpowiedź wcześniejsza, a user agent dokonał już przynajmniej raz próby uwierzytelnienia, a następnie agent użytkownika powinien przedstawić załączoną reprezentację do użytkownika, ponieważ zazwyczaj zawiera istotne informacje diagnostyczne.

A to jest z RFC 2616:

10.4.4 403 Forbidden

Serwer rozumiał prośba, ale odmawia jej spełnienia.
autoryzacja nie pomoże i żądanie nie powinno być powtarzane.
Jeśli metoda żądania nie była HEAD i serwer chce dokonać
publiczne, dlaczego wniosek nie został spełniony, powinien opisywać powód odmowy w jednostce. Jeżeli serwer nie chce Udostępnij te informacje klientowi, kod statusu 404
(Nie znaleziono) może być używany zamiast.

Edit: RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1): semantyka i treść) zmienia znaczenie 403:

6.5.3. 403 Forbidden

Kod statusu 403 (zakazany) wskazuje, że serwer zrozumiałam prośbę, ale odmawiam jej autoryzacji. Serwer, który chce upublicznić, dlaczego żądanie zostało zakazane, może proszę opisać tę przyczynę w ładunku odpowiedzi (jeśli występuje).

Jeśli w zapytaniu podano dane uwierzytelniające, to
serwer uważa je za niewystarczające do przyznania dostępu. Klient
Nie powinien automatycznie powtarzać żądania z tym samym
poświadczenia. Klient może powtórzyć żądanie z nowym lub innym poświadczenia. Jednak żądanie może być zabronione z powodów [18]} niezwiązane z uprawnieniami.

Serwer origin, który chce "ukryć" obecne istnienie
zakazany zasób docelowy może zamiast tego odpowiedzieć kodem stanu
404 (Nie Znalezione).

Zatem 403 może teraz oznaczać wszystko. Podanie nowych poświadczeń może pomóc... albo i nie.

To jest starsze pytanie, ale jedną z opcji, która nigdy nie została podniesiona, było zwrócenie 404. Z punktu widzenia bezpieczeństwa, najwyższa głosowana odpowiedź cierpi na potencjalną lukę wycieku informacji . Powiedzmy na przykład, że dana bezpieczna strona internetowa jest stroną administratora systemu, a może częściej jest rekordem w systemie, do którego Użytkownik nie ma dostępu. Najlepiej, żeby złośliwy użytkownik nawet nie wiedział, że tam jest strona / rekord, nie mówiąc już o że nie mają dostępu. Kiedy buduję coś takiego, spróbuję zarejestrować nieautoryzowane / nieautoryzowane żądania w wewnętrznym dzienniku, ale zwrócę 404.

OWASP posiada więcej informacji o tym, jak atakujący może wykorzystać tego typu informacje w ramach ataku.

To pytanie zostało zadane jakiś czas temu, ale ludzie myślą dalej.

Sekcja 6.5.3 w tym szkicu (autorstwa Fieldinga i Reschke) nadaje kodowi statusu 403 nieco inne znaczenie niż to udokumentowane w RFC 2616 .

Odzwierciedla to, co dzieje się w schematach uwierzytelniania i autoryzacji stosowanych przez wiele popularnych serwerów internetowych i frameworków.

Podkreśliłem to, co uważam za najistotniejsze.

6.5.3. 403 Forbidden

Kod statusu 403 (zakazany) wskazuje, że serwer zrozumiał żądanie, ale odmawia jego autoryzacji. Serwer, który chce podać do publicznej wiadomości, Dlaczego żądanie zostało zakazane, może opisać tę przyczynę w ładunku odpowiedzi (jeśli istnieje).

Jeśli w żądaniu podano dane uwierzytelniające, serwer uważa je za niewystarczające do przyznania dostępu. klient nie powinien powtarzać żądania z tymi samymi poświadczeniami. Na klient może powtórzyć żądanie z nowymi lub innymi poświadczeniami. jednakże wniosek może być zabroniony z przyczyn niezwiązanych z poświadczeniami.

Serwer źródłowy, który chce "ukryć" obecne istnienie zakazanego zasobu docelowego, może zamiast tego odpowiedzieć kodem stanu 404 (Not Found).

Niezależnie od używanej konwencji, ważne jest, aby zapewnić jednolitość w całej witrynie / API.

TL;DR

• 401: odmowa, która ma zwiÄ…zek z uwierzytelnieniem
• 403: Odmowa, która nie ma nic wspólnego z uwierzytelnieniem

Praktyczne Przykłady

If apache wymaga uwierzytelnienia (poprzez .htaccess), i naciÅ›niesz Cancel, odpowie 401 Authorization Required

JeÅ›li nginx znajdzie plik, ale nie ma praw dostÄ™pu (użytkownik / grupa) do odczytu/dostÄ™pu do niego, odpowie za pomocÄ… 403 Forbidden

RFC (2616 sekcja 10)

401 Nieautoryzowano (10.4.2)

Znaczenie 1: potrzeba uwierzytelnienia

Żądanie wymaga uwierzytelnienia użytkownika. ...

Znaczenie 2: Brak autoryzacji

... Jeśli wniosek zawierał już poświadczenia autoryzacji, odpowiedź 401 wskazuje, że odmówiono autoryzacji dla tych poświadczeń. ...

403 Forbidden (10.4.4)

Znaczenie: NiepowiÄ…zane do uwierzytelniania

... Autoryzacja nie pomoże ...

więcej szczegółów:

• Serwer zrozumiaÅ‚ żądanie, ale odmawia jego speÅ‚nienia.

• Powinien opisywać przyczynÄ™ odmowy w jednostce

• Kod statusu 404 (Nie znaleziono) może być użyty zamiast

  (Jeśli serwer chce zachować te informacje z klient)

Nie są zalogowani lub nie należą do odpowiedniej grupy użytkowników

Podałeś dwa różne przypadki; każdy przypadek powinien mieć inną odpowiedź:

1. jeśli w ogóle nie są zalogowani powinieneś zwrócić 401 Nieautoryzowano
2. Jeśli są zalogowani, ale nie należą do odpowiedniej grupy użytkowników, powinieneś zwrócić 403 Forbidden

Myślę, że ważne jest, aby wziąć pod uwagę, że w przeglądarce 401 inicjuje okno dialogowe uwierzytelniania, aby użytkownik wprowadził nowe poświadczenia, podczas gdy 403 nie. Przeglądarki uważają, że jeśli zwracany jest 401, to Użytkownik powinien ponownie uwierzytelnić się. Tak więc 401 oznacza nieprawidłowe uwierzytelnianie, podczas gdy 403 oznacza brak uprawnień.

Oto kilka przypadków w tej logice, w których błąd byłby zwracany z uwierzytelniania lub autoryzacji, z ważnymi frazami pogrubionymi.

• A zasób wymaga uwierzytelnienia, ale Nie podano żadnych poÅ›wiadczeÅ„ .

401: klient powinien określić poświadczenia.

• podane dane uwierzytelniajÄ…ce sÄ… w nieprawidÅ‚owym formacie .

400: to nie jest ani 401, ani 403, ponieważ Błędy składniowe powinny zawsze zwracać 400.

• dane uwierzytelniajÄ…ce odnoszÄ… siÄ™ do użytkownika , który nie istnieje .

401: klient powinien określ prawidłowe poświadczenia.

• podane dane uwierzytelniajÄ…ce sÄ… nieprawidÅ‚owe, ale podaj poprawnego użytkownika (lub nie okreÅ›laj użytkownika, ponieważ OkreÅ›lony użytkownik nie jest wymagany).

401: ponownie, klient powinien określić prawidłowe poświadczenia.

• podane referencje majÄ…wygasÅ‚y .

401: jest to praktycznie to samo, co posiadanie nieprawidłowych poświadczeń w ogóle, więc klient powinien określić poprawne poświadczenia.

• podane dane uwierzytelniajÄ…ce sÄ… caÅ‚kowicie poprawne, ale nie wystarczajÄ… konkretnemu zasobowi , chociaż możliwe jest, że dane uwierzytelniajÄ…ce z wiÄ™kszÄ… iloÅ›ciÄ… uprawnieÅ„ mogÄ….

403: podanie poprawnych poświadczeń nie daje dostępu do zasobu, ponieważ aktualne poświadczenia są już ważne, ale tylko nie mają uprawnień.

• dany zasób jest niedostÄ™pny niezależnie od poÅ›wiadczenia.

403: dzieje się tak niezależnie od poświadczeń, więc podanie prawidłowych poświadczeń nie może pomóc.

• podane dane uwierzytelniajÄ…ce sÄ… caÅ‚kowicie poprawne, ale konkretny klient jest zablokowany przed ich użyciem.

403: jeśli klient jest zablokowany, podanie nowych danych uwierzytelniających nic nie da.

To jest prostsze w mojej głowie niż gdziekolwiek tutaj, więc:

401: musisz HTTP basic auth, aby to zobaczyć.

403: nie widzisz tego, a HTTP basic auth nie pomoże.

Jeśli użytkownik musi się zalogować za pomocą standardowego formularza HTML witryny, 401 nie będzie odpowiedni, ponieważ jest specyficzny dla HTTP basic auth.

Nie polecam używania 403 do odmawiania dostÄ™pu do takich rzeczy jak /includes, ponieważ jeÅ›li chodzi o sieć, te zasoby w ogóle nie istniejÄ… i w zwiÄ…zku z tym 404.

To pozostawia 403 jako "musisz być zalogowany".

Innymi słowy, 403 oznacza "ten zasób wymaga jakiejś formy auth innej niż HTTP basic auth".

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

Biorąc pod uwagę najnowsze RFC w tej sprawie (7231 oraz 7235) przypadek użycia wydaje się dość jasny (dodano kursywę):

• 401 jest dlaunauthenticated ("brak ważnego uwierzytelnienia"); tj. " Nie wiem, kim jesteÅ›, lub nie ufam, że jesteÅ› tym, za kogo siÄ™ podajesz.'

401 Nieautoryzowano

Kod statusu 401 (Nieautoryzowany) wskazuje, że żądanie nie został zastosowany, ponieważ nie jest prawidłowy uwierzytelnianie poświadczenia dla zasobem docelowym. Serwer generujący odpowiedź 401 musi wysłać pole nagłówka WWW-Authenticate (sekcja 4.1) zawierające co najmniej jedno wyzwanie mające zastosowanie do zasobu docelowego.

Jeśli żądanie zawierało dane uwierzytelniające, to 401 odpowiedź wskazuje, że odmówiono autoryzacji dla tych poświadczenia. Agent użytkownika może powtórzyć żądanie z nowym lub zamieniono pole nagłówka autoryzacji (Punkt 4.2). Jeśli 401 odpowiedź Zawiera to samo wyzwanie Co odpowiedź wcześniejsza, a user agent dokonał już przynajmniej raz próby uwierzytelnienia, a następnie agent użytkownika powinien przedstawić załączoną reprezentację do użytkownika, ponieważ zazwyczaj zawiera istotne informacje diagnostyczne.

• 403 jest dla nieautoryzowano ("odmawia autoryzacji"); tzn. " wiem, kim jesteÅ›, ale nie masz uprawnieÅ„ do dostÄ™pu do tego zasoby.'

403 Forbidden

Kod statusu 403 (zakazany) wskazuje, że serwer rozumiał wniosek, ale odmawia autoryzacji go. Serwer, który chce upublicznić, dlaczego żądanie zostało zakazane, można opisać, że przyczyna w ładunku odpowiedzi (jeśli występuje).

Jeśli w zapytaniu podano dane uwierzytelniające, serwer uważa je za niewystarczające do przyznania dostępu. Klient Nie powinien automatycznie powtarzać żądania z tym samym poświadczenia. Klient może powtórzyć żądanie z nowym lub innym poświadczenia. Jednak wniosek może być zabroniony z przyczyn niezwiązane z uprawnieniami.

Serwer origin, który chce "ukryć" obecne istnienie zakazany zasób docelowy może zamiast tego odpowiedzieć kodem stanu 404 (Nie Znaleziono)

W przypadku 401 vs 403 odpowiedziano na to wiele razy. Jest to zasadniczo debata "HTTP request environment", a nie debata "application".

Wydaje się być pytanie w sprawie roll-your-own-login (aplikacja).

W tym przypadku po prostu brak zalogowania nie wystarczy, aby wysłać 401 lub 403, chyba że użyjesz http Auth vs strona logowania (nie związana z ustawieniem http Auth). Wygląda na to, że możesz szukać "2010", z rolką-własnego-logowania screen present (zamiast żądanego zasobu) dla dostępu do pliku na poziomie aplikacji. Tu jest napisane:

"słyszałem cię, jest tutaj, ale spróbuj tego zamiast tego (nie możesz tego zobaczyć)"