Kod statusu HTTP 401 czy 403? Jak różnią się błędy uwierzytelnienia i autoryzacji

Za każdym razem, gdy ładujesz stronę internetową, dokonujesz płatności lub logujesz się do aplikacji, następuje niewidoczna rozmowa między twoim urządzeniem a serwerem. To trochę jak wysyłanie wiadomości i czekanie na odpowiedź — czasem jest to kciuk do góry, czasem uprzejme „spróbuj ponownie”, a czasami bezpośrednie „nie”. Te odpowiedzi, znane jako kody statusu HTTP, są niewidocznymi bohaterami internetu, które cicho kierują przepływem komunikacji i zapewniają płynne działanie wszystkiego — lub przynajmniej dają znać, gdy coś nie działa.

Co to są kody statusu HTTP#

Kody statusu HTTP są jak sygnały w rozmowie między klientem (takim jak przeglądarka lub aplikacja) a serwerem. Dostarczają szybkich i jasnych informacji o tym, co się stało, gdy wysłałeś żądanie — czy wszystko poszło gładko, coś poszło nie tak, czy potrzebne są dodatkowe działania. Pomyślmy o tym jak o wizycie w dobrze prowadzonym piekarni:

200: Wszystko jest doskonałe#

Proszisz o rogalika, a piekarz się uśmiecha, podaje go i mówi: „Proszę bardzo!” To jest HTTP 200 OK — żądanie zakończyło się sukcesem, a wszystko działało zgodnie z oczekiwaniami.

Kod statusu HTTP 200 OK jest jednym z najczęściej używanych kodów, wskazując, że żądanie od klienta zostało pomyślnie odebrane, zrozumiane i przetworzone przez serwer.

301: Przenieśliśmy się#

Docierasz do swojej ulubionej piekarni, ale widzisz znak informujący „Przenieśliśmy się na 123 Nowa Ulica”. To jest 301 Moved Permanently. Serwer mówi przeglądarce, aby automatycznie skierowała na nowy adres.

Kod statusu HTTP 301 Moved Permanently wskazuje, że żądany zasób został trwale przeniesiony na nowy URL. Ten kod statusu informuje klienta (np. przeglądarkę lub klienta API), aby zaktualizował swoje zapisy i używał nowego URL do przyszłych żądań.

404: Przepraszam, tego tutaj nie ma#

Proszisz o czekoladową bułkę, a piekarz mówi: „Nie robimy ich tutaj”. To jest 404 Not Found — zasób, którego szukasz, nie istnieje na serwerze.

Kod statusu HTTP 404 Not Found wskazuje, że serwer nie mógł znaleźć żądanego zasobu. Ta odpowiedź oznacza, że żądanie klienta było prawidłowe, ale serwer nie mógł zlokalizować zasobu, o który proszono.

401: Kim jesteś?#

Próbujesz wejść do salonu VIP, ale ochroniarz cię zatrzymuje i mówi: „Musisz pokazać kartę członkowską.” To jest 401 Unauthorized — wymagana jest autoryzacja przed dostępem do zasobu.

Kod statusu HTTP 401 Unauthorized wskazuje, że żądanie klienta nie zostało zastosowane, ponieważ brakuje mu ważnych danych uwierzytelniających. Serwer wymaga, aby klient uwierzytelnił się, aby uzyskać dostęp do żądanego zasobu.

403: Nie dla ciebie#

Pokazujesz swoją kartę członkowską, ale ochroniarz mówi: „Tylko członkowie platynowi mogą wejść.” To jest 403 Forbidden — jesteś uwierzytelniony, ale nie masz uprawnień potrzebnych do uzyskania dostępu do zasobu.

Kod statusu HTTP 403 Forbidden wskazuje, że serwer rozumie żądanie klienta, ale odmawia jego spełnienia ze względu na brak uprawnień. Jest to różne od statusu 401 Unauthorized, ponieważ klient jest uwierzytelniony (lub żądanie nie wymaga uwierzytelnienia), ale dostęp do zasobu jest wyraźnie zabroniony.

500: Piekarnik się pali#

Składasz zamówienie, ale nagle z kuchni zaczyna wydobywać się dym. Piekarz mówi: „Nie możemy zrealizować twojego zamówienia; coś poszło źle wewnętrznie.” To jest 500 Internal Server Error — serwer napotkał niespodziewany problem.

Kod statusu HTTP 500 Internal Server Error wskazuje, że serwer napotkał niespodziewany stan, który uniemożliwił mu zrealizowanie żądania. Jest to ogólna odpowiedź błędu i nie dostarcza szczegółowych informacji o tym, co poszło źle.

503: Tymczasowo niedostępne#

Odwiedzasz piekarnię, ale widzisz znak „Zamknięte z powodu konserwacji”. Piekarnia ponownie otworzy się później. To jest 503 Service Unavailable — serwer jest tymczasowo niezdolny do obsługi twojego żądania, często z powodu przeciążenia lub konserwacji.

Kod statusu HTTP 503 Service Unavailable wskazuje, że serwer jest tymczasowo niezdolny do obsługi żądania. Może to być spowodowane przeciążeniem serwera, konserwacją lub innymi tymczasowymi warunkami. W przeciwieństwie do 500 Internal Server Error, 503 sugeruje, że problem prawdopodobnie zostanie wkrótce rozwiązany.

Kody statusu HTTP są kluczowe dla utrzymania efektywnej komunikacji między klientami a serwerami. Szybko informują klientów, czy ich żądania zakończyły się sukcesem, niepowodzeniem czy wymagają dalszych działań. Dla deweloperów i profesjonalistów IT zrozumienie tych kodów pomaga debugować problemy, projektować lepsze zarządzanie błędami i poprawiać ogólne doświadczenia użytkowników.

Traktuj je jak profesjonalne, standardowe sygnały w ciągłej rozmowie internetu.

W tym artykule chciałbym skupić się na błędach 401 i 403, ponieważ są one ściśle związane z uwierzytelnieniem (AuthN) i autoryzacją (AuthZ).

Kiedy używać 401 Unauthorized?#

Kod statusu HTTP 401 Unauthorized jest używany, gdy żądanie klienta wymaga uwierzytelnienia, ale jest ono albo brakujące, nieważne, albo nieudane. Informuje klienta, że musi się uwierzytelnić, aby uzyskać dostęp do żądanego zasobu. Związek między uwierzytelnieniem a statusem 401 Unauthorized polega na roli uwierzytelnienia w określaniu, czy żądanie może zostać przetworzone.

401 Unauthorized musi zawierać nagłówek WWW-Authenticate z informacjami o tym, jak się uwierzytelnić.

Jakie są więc typowe scenariusze dla użycia 401 Unauthorized?

1. Brakujące uwierzytelnienie

   Żądanie nie zawiera wymaganych danych uwierzytelniających. Na przykład: Żądanie do chronionego punktu końcowego API jest składane bez nagłówka Authorization.

2. Nieważne dane uwierzytelniające

   Klient podaje dane uwierzytelniające, ale są one niepoprawne lub nie odpowiadają oczekiwaniom serwera. Na przykład, użytkownik przesyła nieważny klucz API lub błędnie sformułowany token.

3. Wygasły token uwierzytelniający

   Token uwierzytelniający jest ważny, ale wygasł, co wymaga ponownego uwierzytelnienia klienta. Na przykład, token JWT z przeszłym terminem wygaśnięcia (klauzula exp).

4. Brakujący lub błędnie sformułowany nagłówek autoryzacji

   Nagłówek autoryzacji jest wymagany, ale jest albo nie podany, albo błędnie sformułowany.

5. Niewspierany schemat uwierzytelnienia

   Serwer nie wspiera metody uwierzytelnienia podanej przez klienta. Na przykład: Klient przesyła nagłówek autoryzacji Basic, ale serwer obsługuje tylko tokeny Bearer.

6. Nieważna sesja lub unieważnienie tokenu

   Sesja użytkownika została unieważniona lub jego token został wycofany. Na przykład: Użytkownik wylogowuje się, ale ten sam token jest używany do dostępu do chronionego zasobu.

Przykładowa odpowiedź

Kiedy używać 403 Forbidden?#

Kod statusu HTTP 403 Forbidden oznacza, że serwer rozumie żądanie i tożsamość klienta (jeśli jest uwierzytelniony), ale odmawia dostępu z powodu niewystarczających uprawnień. Wyraźnie sygnalizuje: „Nie możesz tego zrobić”, zapewniając jasne granice dostępu i wzmacniając polityki bezpieczeństwa.

Różnica między 401 Unauthorized a 403 Forbidden leży w ich rolach w kontekstach uwierzytelnienia i autoryzacji.

Autoryzacja jest oddzielnym mechanizmem od uwierzytelnienia. Podczas gdy uwierzytelnienie identyfikuje, kim jesteś, autoryzacja określa, czy możesz uzyskać dostęp do określonych zasobów i jakie działania możesz na nich wykonywać.

Aby sprawdzić szczegółowe różnice między authN a authZ. Sprawdź poniższe artykuły.

Co to jest AuthZ

Co to jest AuthN

Jakie są więc typowe scenariusze dla użycia 403 Forbidden?

1. Uwierzytelniony, ale brak uprawnienia

   Klient jest zalogowany lub uwierzytelniony, ale nie ma wymaganych uprawnień lub roli. Na przykład, użytkownik z rolą „obserwatora” próbuje usunąć plik, co wymaga uprawnień „edytora”.

2. Ograniczony dostęp do zasobów

   Dostęp do zasobu jest celowo ograniczony do określonych użytkowników lub grup. Na przykład: Prywatny dokument udostępniony określonym użytkownikom jest dostępny przez kogoś, kto nie znajduje się na liście dostępu.

3. Blokowanie IP lub geograficzne

   Adres IP klienta lub lokalizacja geograficzna jest blokowana przez serwer. Na przykład: użytkownik z zastrzeżonego regionu próbuje uzyskać dostęp do usługi, która działa tylko w określonych krajach.

4. Blokowane akcje przez politykę

   Klient próbuje wykonać akcję zabronioną przez polityki lub zasady po stronie serwera. Na przykład: użytkownik próbuje zmodyfikować zasób, który jest oznaczony jako „tylko do odczytu.”

5. Blokowane zasoby statyczne

   Serwer odmawia dostępu do określonych plików statycznych lub katalogów ze względów bezpieczeństwa.

   Na przykład: Użytkownik próbuje uzyskać dostęp do pliku .htaccess lub pliku konfiguracyjnego serwera.

6. Konto zawieszone lub wyłączone

   Konto klienta jest zawieszone lub zablokowane z powodu naruszeń lub nieaktywności. Na przykład: Użytkownik z zawieszonym kontem próbuje się zalogować lub uzyskać dostęp do zasobów.

7. Akcja wymaga podwyższonych uprawnień

   Żądana akcja wymaga specjalnych uprawnień (np. administratora lub superużytkownika). Na przykład: Użytkownik standardowy próbuje uzyskać dostęp do punktów końcowych tylko dla administratorów.

Przykładowa odpowiedź

Jak mogę rozwiązać problem z błędem 401 unauthorized#

Błąd 401 zazwyczaj wskazuje, że wymagane jest uwierzytelnienie i nie powiodło się.

Sprawdź dane uwierzytelniające#

Upewnij się, że nagłówek Authorization jest obecny i prawidłowo sformułowany oraz zweryfikuj, czy dane uwierzytelniające (klucz API, token lub hasło) są poprawne i nie wygasły. Wprowadzenie błędnego nazwy użytkownika lub hasła jest jednym z najczęstszych powodów wystąpienia błędu 401.

Potwierdź metodę uwierzytelnienia#

Serwer może oczekiwać innej metody uwierzytelnienia niż ta, która jest dostarczana. Może się to zdarzyć, jeśli klient i serwer nie są zgodni co do protokołu uwierzytelnienia. Użyj prawidłowej metody (np. Basic, Bearer, API Key), jak określone przez serwer, i sprawdź poprawność składni w nagłówkach.

Zbadaj odpowiedź serwera#

Przejrzyj ciało odpowiedzi pod kątem szczegółów błędu i zobacz nagłówek WWW-Authenticate dla instrukcji uwierzytelnienia.

Zweryfikuj żądanie#

Potwierdź, że punkt końcowy, parametry zapytania i host są poprawne oraz upewnij się, że zasób, do którego masz dostęp, wymaga uwierzytelnienia.

Sprawdź problemy z tokenem#

Dekoduj i sprawdź token (np. za pomocą https://logto.io/jwt-decoder) pod kątem ważności, wygaśnięcia i roszczeń oraz dopasuj odbiorcę tokena (aud) do wymagań API.

Jak mogę rozwiązać problem z błędem 403 forbidden#

Błąd 403 forbidden zazwyczaj oznacza, że proces autoryzacji został zakończony, ale dostęp został odmówiony. Aby rozwiązać ten błąd, rozważ następujące warunki:

Zweryfikuj uprawnienia#

Potwierdź, że twoje konto, klucz API lub token ma wymagane uprawnienia do zasobu. Sprawdź, czy zasób jest ograniczony do określonych ról lub grup.

Upewnij się, że uwierzytelnienie jest poprawne#

Upewnij się, że jesteś poprawnie uwierzytelniony (np. za pomocą ważnego tokena lub danych uwierzytelniających).

Sprawdź dwukrotnie metodę uwierzytelnienia wymaganą przez serwer.

Zweryfikuj zasób#

Potwierdź, że żądany zasób istnieje i masz do niego dostęp. Jeśli używasz interfejsów API, zweryfikuj wymagania punktu końcowego w dokumentacji.

Sprawdź blokowanie IP lub lokalizacji#

Sprawdź, czy twój adres IP lub lokalizacja geograficzna nie jest zastrzeżona przez serwer.

Przejrzyj polityki serwera#

Upewnij się, że żądana akcja nie narusza zasad ani polityk po stronie serwera (np. dostęp do zasobu tylko do odczytu).

Zbadaj odpowiedź serwera#

Sprawdź ciało odpowiedzi pod kątem szczegółów wyjaśniających przyczynę błędu 403.

Czy jedno żądanie może zwrócić zarówno kody statusu 401, jak i 403#

Nie, jedno żądanie HTTP nie może zwrócić jednocześnie zarówno kodów statusu 401 Unauthorized, jak i 403 Forbidden, ponieważ odpowiedź HTTP może zawierać tylko jeden kod statusu.

Praktyczne zastosowanie kodów błędów 401 i 403 w uwierzytelnieniu i autoryzacji#

We współczesnym rozwoju aplikacji 401 Unauthorized i 403 Forbidden to dwa kody statusu HTTP, które deweloperzy napotykają często. Chociaż mogą wydawać się podobne, ich znaczenie i przypadki użycia są wyraźnie różne. Aby wyjaśnić ich różnice, ten artykuł bada praktyczne przykłady tych kodów w scenariuszach takich jak uwierzytelnienie, autoryzacja, multi-tenancja i uwierzytelnienie wieloskładnikowe (MFA).

1. Scenariusz logowania: Użytkownik próbuje uzyskać dostęp do chronionej strony bez zalogowania się lub podania prawidłowych danych logowania. Serwer odpowiada i rzuca błąd 401 Unauthorized: „Musisz się zalogować lub podać ważne dane logowania, aby uzyskać dostęp do tej strony.”
2. Scenariusz kontroli dostępu: Ten sam użytkownik poprawnie zaloguje się, ale próbuje uzyskać dostęp do strony dostępnej tylko dla administratorów bez wymaganego uprawnienia administratora. Serwer odpowiada i rzuca błąd 403 Forbidden: „Jesteś zalogowany, ale nie masz uprawnień do uzyskania dostępu do tej strony.”
3. Scenariusz multi-tenancy: Ten sam użytkownik zaloguje się, ale należy do Najemcy A i próbuje uzyskać dostęp do zasobu w Najemcy B, gdzie nie ma dostępu. Serwer odpowiada i rzuca błąd 403 Forbidden: „Jesteś uwierzytelniony, ale nie masz uprawnień do uzyskania dostępu do tego zasobu w Najemcy B.”
4. Scenariusz MFA: Użytkownik próbuje się zalogować, ale nie ukończył wymaganego uwierzytelnienia wieloskładnikowego (MFA). Serwer odpowiada i rzuca błąd 401 Unauthorized: „Uwierzytelnienie jest niekompletne. Proszę ukończyć MFA, aby kontynuować.”

Korzystanie z Logto jako dostawcy uwierzytelnienia i autoryzacji#

Logto jest przede wszystkim dostawcą uwierzytelnienia, oferującym kluczowe metody, takie jak logowanie bez hasła, e-mail i hasło, MFA, SSO dla przedsiębiorstw oraz logowanie społecznościowe, wszystko na podstawie otwartych standardowych protokołów, takich jak OIDC, OAuth 2.0 i SAML.

Logto Cloud zapewnia także niezbędne funkcje autoryzacji, w tym kontrolę dostępu opartą na rolach (RBAC), organizacje (multi-tenancy) oraz niestandardowe roszczenia tokenowe, aby sprostać różnorodnym potrzebom autoryzacji.