nieprawidłowy nagłówek autoryzacyjny

Nieprawidłowy nagłówek autoryzacyjny to błędnie sformułowane pole Authorization, skutkujące odrzuceniem żądania.

Nieprawidłowy nagłówek autoryzacyjny w żądaniu HTTP

Nieprawidłowy nagłówek autoryzacyjny oznacza, że pole Authorization w żądaniu HTTP nie ma formatu oczekiwanego przez serwer. Nagłówek ten przekazuje dane uwierzytelniające według określonego schematu, na przykład Basic albo Bearer. Sama obecność pola nie wystarcza: serwer musi rozpoznać nazwę schematu, poprawnie odczytać jego parametr oraz sprawdzić zgodność przekazanych danych z wymaganiami danej usługi.

Przykładowo zapis Authorization: Bearer token wskazuje na użycie tokenu typu Bearer, natomiast schemat Basic wymaga przekazania zakodowanej w Base64 pary nazwy użytkownika i hasła w postaci nazwa:hasło. Kodowanie Base64 nie jest szyfrowaniem. Błąd może wynikać między innymi z pominięcia słowa Bearer, użycia niewłaściwego separatora, wstawienia pustego tokenu, pozostawienia dodatkowych znaków albo przekazania nagłówka w innym miejscu niż nagłówki żądania.

Jak serwer interpretuje pole Authorization

Podczas obsługi żądania serwer najpierw analizuje składnię nagłówka, a następnie ustala, czy dany schemat autoryzacji jest dozwolony dla wskazanego zasobu. Jeżeli nagłówek jest całkowicie nieczytelny lub ma nieobsługiwany schemat, odpowiedź może mieć status 400 Bad Request albo 401 Unauthorized, zależnie od implementacji. Status 401 oznacza brak prawidłowego uwierzytelnienia, a nie automatycznie brak uprawnień do konkretnej operacji. Do odmowy wynikającej z niewystarczających uprawnień częściej stosuje się status 403 Forbidden.

Dla odpowiedzi 401 serwer może dołączyć nagłówek WWW-Authenticate, który informuje klienta, jaki schemat uwierzytelniania jest wymagany. Przykładowo WWW-Authenticate: Bearer sygnalizuje oczekiwanie tokenu Bearer. W przypadku OAuth 2.0 token Bearer jest zwykle przekazywany właśnie w polu Authorization, zgodnie z zasadami opisanymi w RFC 6750. Serwer może także odrzucić poprawnie sformułowany nagłówek, gdy token wygasł, został unieważniony, dotyczy innej usługi albo nie zawiera wymaganych zakresów dostępu.

Ważne jest rozróżnienie błędu składni od błędu wartości. Nagłówek Authorization: Bearer bez parametru ma inną wadę niż nagłówek z poprawnym tokenem, który utracił ważność. Podobnie poprawnie zakodowane dane Basic mogą prowadzić do odmowy, jeśli konto nie istnieje lub hasło jest nieprawidłowe. Log serwera albo komunikat klienta powinien wskazywać, na którym etapie nastąpiło odrzucenie, lecz treści tokenów i haseł nie powinny być zapisywane w logach.

Sprawdzanie klienta, adresu żądania i kodowania

Diagnostykę rozpoczyna się od ustalenia, który program wysyła żądanie: przeglądarka, aplikacja desktopowa, skrypt, biblioteka programistyczna czy narzędzie systemowe. Następnie trzeba porównać rzeczywiste nagłówki z dokumentacją konkretnego interfejsu. W praktyce należy sprawdzić, czy klient wysyła właściwą metodę HTTP, poprawny adres zasobu, oczekiwany schemat oraz aktualną wartość tokenu. Przydatne jest porównanie żądania działającego z żądaniem odrzucanym, z pominięciem poufnych danych.

Problemy powodują także różnice w kodowaniu znaków i automatycznym przetwarzaniu nagłówków. W schemacie Basic dane przed zakodowaniem muszą mieć właściwy układ, a wynik Base64 nie może zawierać przypadkowych znaków końca wiersza. W schemacie Bearer token powinien zostać przekazany jako jedna wartość zgodna z wymaganiami dostawcy. Nie należy dopisywać cudzysłowów, prefiksu Bearer drugi raz ani wstawiać tokenu do adresu URL, jeśli dokumentacja przewiduje nagłówek.

W aplikacji warto sprawdzić, czy pośrednie komponenty nie usuwają pola Authorization albo nie zastępują go wartością z konfiguracji. Takie zachowanie może wystąpić po zmianie adresu API, przekierowaniu, użyciu niewłaściwego profilu środowiska lub błędnym ustawieniu zmiennej konfiguracyjnej. Pomocne są narzędzia deweloperskie przeglądarki, dzienniki klienta oraz śledzenie kodu odpowiedzi HTTP. Diagnostyka powinna ujawniać jedynie nazwę schematu i informację o obecności tokenu, bez wyświetlania pełnych danych uwierzytelniających.

Naprawa konfiguracji autoryzacji w aplikacji

Usunięcie problemu polega na odtworzeniu wymaganego formatu nagłówka i zapewnieniu, aby klient korzystał z właściwych danych dla danego środowiska. Jeżeli token wygasł, trzeba pobrać nowy zgodnie z procedurą używaną przez konkretną aplikację. Jeżeli problem dotyczy Basic, należy ponownie sprawdzić nazwę użytkownika, hasło, kodowanie oraz sposób budowania nagłówka. Jeśli serwer zwraca 401 mimo poprawnej składni, należy zweryfikować ważność tokenu, jego odbiorcę, zakresy i uprawnienia po stronie usługi.

Po zmianie konfiguracji należy wykonać kontrolne żądanie do właściwego zasobu i sprawdzić kod odpowiedzi, nagłówki oraz zachowanie aplikacji. Nie powinno się bezrefleksyjnie wyłączać uwierzytelniania ani przenosić danych logowania do parametrów adresu. Warto również wykluczyć lokalne przyczyny, takie jak nieaktualna aplikacja, uszkodzona pamięć podręczna, rozszerzenie przeglądarki modyfikujące żądania lub błędnie zapisany plik konfiguracyjny.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, w tym diagnostyką problemów z konfiguracją aplikacji oraz komunikacją sieciową w popularnym oprogramowaniu użytkowym. Przy zgłoszeniu warto przekazać nazwę programu, adres usługi bez danych poufnych, kod odpowiedzi HTTP i moment wystąpienia problemu. Takie informacje ułatwiają odróżnienie nieprawidłowego formatu nagłówka od wygasłego uwierzytelnienia lub niedostępności samej usługi.