Angielskie słowa authentication i authorization są często mylone i używane zamiennie podczas gdy są to pojęcia znaczące zupełnie co innego. Authentication czyli polskie uwierzytelnienie (błędnie niekiedy tłumaczone jako autentykacja) oznacza identyfikację tożsamości, inaczej mówiąc odpowiada na pytanie z kim mamy do czynienia. Z kolei authorization po polsku autoryzacja to weryfikacja uprawnień.
Jeśli dostęp do jakichś zasobów na stronie jest ograniczony dla wybranej grupy użytkowników – np. dostęp do panelu administracyjnego – wtedy najpierw należy dokonać uwierzytelnienia tj. rozpoznać kim jest użytkownik żądający dostępu do zasobu, a dopiero później go autoryzować czyli sprawdzić, czy zalogowany użytkownik ma odpowiednie uprawnienia.
W wielu serwisach użytkowników niezalogowanych tzw. no name-ów określa się w bardziej elegancki sposób mianem gości. W sytuacji kiedy taki gość wpisuje w przeglądarce adres strony, która wymaga logowania w większości przypadków przekierowuje się go na stronę logowania. Pomysł jak najbardziej słuszny, tyle że przy okazji zapomina się o wysłaniu odpowiedniego nagłówka HTTP 401 Unauthorized. (Uwaga – opis kodu odpowiedzi 401 może niektórych wprowadzić w błąd nie mniej używa się go przy uwierzytelnianiu a nie autoryzacji. Należy go sobie tłumaczyć jako „nieautoryzowany dostęp – żądanie zasobu, który wymaga uwierzytelnienia”. Na dobrą sprawę należało by ten nagłówek zwracać również w chwili kiedy, użytkownik poda niewłaściwe dane i nie uda mu się zalogować na stronie.
Można by zadać pytanie po co w ogóle bawić się w te nagłówki. Otóż wspomniany wyżej gość to niezidentyfikowany użytkownik. Jest on do tego stopnia nierozpoznany, że nie wiadomo nawet czy jest on człowiekiem, czy np. pajączkiem indeksującym serwis na potrzeby wyszukiwarki stron. Taki program otrzymując odpowiedni nagłówek następnym razem wchodząc na nasz serwis ominie odsyłacz do chronionej strefy oszczędzając w ten sposób cenny czas i zasoby naszego serwera.
Rozpatrzmy teraz drugi przypadek kiedy użytkownik jest już zalogowany, ale próbuje się dostać do strefy, do której nie ma uprawnień. Także w tym przypadku użytkownik może być maszyną choćby w postaci pośrednika usługi sieciowej. Tu można przyjąć kilka strategii.
- można wyświetlić komunikat o braku uprawnień zwracając równocześnie kod 403 Forbidden
- można zwrócić kod błędu 404 i udać, że takiej strony nie ma,
- można automatycznie wygasić sesję użytkownika i przekierować na stronę logowania,
Nagłówek 403 Forbidden informuje o tym, że żądany zasób istnieje ale bieżący użytkownik nie ma wystarczających uprawnień aby się do niego dostać. Automatowi taka odpowiedź w zupełności wystarczy, z kolei człowiekowi przydało by się jeszcze wyświetlić odpowiedni komunikat i formularz logowania lub przynajmniej odsyłacz do takowego.
Zwrócenie kodu 404 nie jest może do końca poprawne, gdyż wprowadza w błąd, jednak ze względów bezpieczeństwa można pokusić się o takie małe oszustwo celem ukrycia przed nieuprawnionym użytkownikiem samego faktu istnienia chronionego zasobu.
Ostatnia z wymienionych jest moim zdaniem najgorszym z rozwiązań gdyż nie daje użytkownikowi możliwości rezygnacji z dostępu do chronionego zasobu tylko każe go koniecznością powtórnego uwierzytelnienia. Poza tym sytuacja ta jest nieco kłopotliwa z punktu widzenia zwracanych nagłówków, gdyż w pierwszej kolejności powinniśmy zwrócić kod 403 Forbidden, a zaraz potem kod 401 Unauthorized, a w jednym żądaniu możemy zwrócić tylko jeden.
