OAuth

OAuth to standard autoryzacji pozwalający udzielić aplikacji dostępu do zasobów bez ujawniania jej hasła użytkownika.

OAuth jako mechanizm delegowania dostępu

OAuth jest protokołem delegowania autoryzacji. Pozwala aplikacji uzyskać ograniczony dostęp do zasobów należących do użytkownika bez przekazywania tej aplikacji hasła do konta. Przykładem może być program, który chce odczytać określone dane z usługi internetowej. Zamiast otrzymać dane logowania, aplikacja kieruje użytkownika do serwera autoryzacji, gdzie następuje uwierzytelnienie oraz zatwierdzenie zakresu dostępu. Po pomyślnej decyzji aplikacja otrzymuje token, a nie hasło.

OAuth nie jest samodzielnym mechanizmem potwierdzania tożsamości użytkownika. Jego podstawowym zadaniem jest określenie, czy dana aplikacja może korzystać z określonych zasobów i w jakim zakresie. Uwierzytelnienie może odbywać się za pomocą hasła, klucza sprzętowego, aplikacji jednorazowych kodów lub innego mechanizmu obsługiwanego przez dostawcę usługi. Jeżeli potrzebne jest przekazanie aplikacji informacji o tym, kim jest użytkownik, często stosuje się OpenID Connect, który rozszerza OAuth 2.0 o warstwę tożsamości.

Role uczestników i tokeny w OAuth 2.0

W typowym przepływie OAuth 2.0 występują cztery role. Właściciel zasobu wyraża zgodę na dostęp, klient jest aplikacją żądającą uprawnień, serwer autoryzacji obsługuje logowanie i zgodę, a serwer zasobów udostępnia chronione dane. W praktyce serwer autoryzacji i serwer zasobów mogą należeć do tej samej platformy, ale pełnią różne funkcje logiczne. Klient nie powinien samodzielnie przetwarzać hasła użytkownika przekazywanego do dostawcy usługi.

Token dostępu jest poświadczeniem przedstawianym serwerowi zasobów. Zwykle ma ograniczony czas ważności i zakres, określany między innymi przez parametr scope. Token może zezwalać na odczyt danych, zapis danych albo wykonanie innej ściśle określonej operacji. Token odświeżający, czyli refresh token, może służyć do uzyskania nowego tokenu dostępu po jego wygaśnięciu, ale nie jest przesyłany do każdego żądania zasobu. Token dostępu powinien być traktowany jak poufne poświadczenie, ponieważ jego posiadacz może wykonać operacje objęte przyznanym zakresem.

OAuth 2.0 rozróżnia między innymi klienta poufnego, który potrafi bezpiecznie przechować sekret, oraz klienta publicznego, takiego jak aplikacja mobilna lub program uruchamiany w przeglądarce. Sekretu klienta nie można wiarygodnie ukryć w kodzie dostarczonym na urządzenie użytkownika. Z tego powodu sposób ochrony klienta publicznego musi być dobrany do konkretnego typu aplikacji i przepływu.

Przepływ Authorization Code i ochrona żądania

Jednym z najczęściej stosowanych przepływów jest Authorization Code. Aplikacja przekierowuje użytkownika do serwera autoryzacji, przekazując między innymi identyfikator klienta, adres przekierowania oraz żądany zakres. Po zalogowaniu i wyrażeniu zgody serwer autoryzacji zwraca do zarejestrowanego adresu krótko żyjący kod autoryzacyjny. Aplikacja przesyła ten kod do serwera autoryzacji i otrzymuje token dostępu. Kod nie jest właściwym tokenem dostępu i powinien zostać wymieniony tylko raz.

W aplikacjach publicznych stosuje się mechanizm PKCE, czyli Proof Key for Code Exchange. Klient tworzy losowy parametr code_verifier, wylicza z niego wartość code_challenge i wysyła wyzwanie podczas rozpoczęcia autoryzacji. Przy wymianie kodu musi przedstawić pierwotny weryfikator. Serwer autoryzacji sprawdza zgodność obu wartości, dzięki czemu przechwycony kod jest trudniejszy do wykorzystania przez inną aplikację. Ważnym elementem jest także parametr state, który pozwala klientowi powiązać odpowiedź z rozpoczętym żądaniem i ograniczyć ryzyko niepożądanego podstawienia odpowiedzi.

Adres przekierowania musi być kontrolowany przez właściciela klienta i zgodny z konfiguracją dostawcy OAuth. Niedokładne dopasowanie adresu, przesyłanie tokenów w niechronionym kanale albo umieszczenie danych uwierzytelniających w logach może prowadzić do przejęcia uprawnień. Komunikacja z serwerem autoryzacji i serwerem zasobów powinna odbywać się przez HTTPS. Zakresy uprawnień warto ograniczać do minimum potrzebnego do działania konkretnej funkcji.

OAuth w praktyce serwisowej i na komputerze użytkownika

Problemy z logowaniem przez OAuth mogą wynikać z błędnej daty i godziny systemowej, nieaktualnej przeglądarki, uszkodzonych danych sesji, blokowania przekierowań albo niezgodnego adresu zwrotnego skonfigurowanego w aplikacji. Znaczenie ma również wybór konta w przeglądarce oraz to, czy aplikacja korzysta z właściwego identyfikatora klienta. Sam komunikat o odrzuceniu autoryzacji nie przesądza jeszcze o awarii systemu operacyjnego lub sprzętu.

Podczas analizy warto sprawdzić pełny adres przekierowania, kod błędu zwrócony przez dostawcę, moment wygaśnięcia tokenu oraz zakres żądanych uprawnień. Nie należy kopiować tokenów dostępu do zgłoszeń, publicznych forów ani zwykłych plików dziennika. Jeżeli problem występuje tylko w jednym programie, przyczyną może być jego konfiguracja lub integracja z dostawcą usługi. Jeżeli przekierowania i logowanie nie działają w wielu aplikacjach, należy dodatkowo sprawdzić przeglądarkę, certyfikaty, ustawienia sieciowe i lokalny czas.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego w przypadku problemów z działaniem aplikacji na komputerze można zlecić diagnostykę przyczyn związanych ze środowiskiem urządzenia. Zakres oceny powinien obejmować między innymi system, przeglądarkę, połączenie sieciowe oraz sposób występowania błędu, bez ujawniania haseł i tokenów.