uwierzytelnianie OAuth

Uwierzytelnianie OAuth pozwala udzielić aplikacji dostępu do zasobów bez ujawniania hasła użytkownika.

Na czym polega uwierzytelnianie OAuth

OAuth jest mechanizmem delegowania uprawnień, który pozwala aplikacji uzyskać ograniczony dostęp do zasobów użytkownika przechowywanych przez inną usługę. Użytkownik loguje się bezpośrednio u dostawcy zasobu, a aplikacja otrzymuje token dostępu zamiast hasła. Dzięki temu aplikacja nie musi znać ani przechowywać hasła do konta użytkownika. Przykładowo program może otrzymać zgodę na odczyt określonych danych z konta, ale nie uzyska automatycznie prawa do zmiany hasła, usuwania konta ani dostępu do innych zasobów, jeżeli takie uprawnienia nie zostały przyznane.

Ściśle technicznie OAuth 2.0 jest przede wszystkim protokołem autoryzacji, czyli określania, do jakich zasobów aplikacja może się odwoływać. Sam OAuth 2.0 nie definiuje pełnego mechanizmu potwierdzania tożsamości użytkownika. Do logowania użytkownika i przekazywania informacji o jego tożsamości często stosuje się OpenID Connect, który działa jako warstwa tożsamości nad OAuth 2.0 i wykorzystuje między innymi token ID. Dlatego określenie „uwierzytelnianie OAuth” jest powszechne, ale w dokumentacji technicznej warto rozróżniać uwierzytelnianie od autoryzacji.

Przebieg uzyskiwania zgody i tokenu

W typowym przepływie OAuth 2.0 aplikacja występuje jako klient, usługa przechowująca dane jako serwer zasobów, a system obsługujący logowanie i wydawanie tokenów jako serwer autoryzacyjny. Klient przekierowuje użytkownika do serwera autoryzacyjnego, przekazując między innymi identyfikator klienta, adres powrotu oraz zakres żądanych uprawnień. Użytkownik loguje się na stronie dostawcy i zatwierdza zgodę. Po pomyślnej autoryzacji serwer przekierowuje przeglądarkę na wcześniej zarejestrowany adres klienta.

W zalecanym dla aplikacji internetowych przepływie Authorization Code klient otrzymuje najpierw kod autoryzacyjny, a nie właściwy token dostępu. Kod jest następnie wymieniany na token podczas żądania do serwera autoryzacyjnego. Kod ma krótki czas życia i jest przeznaczony do jednorazowego użycia. W aplikacjach publicznych, takich jak programy mobilne i aplikacje działające w przeglądarce, stosuje się dodatkowo PKCE, opisane w RFC 7636. Klient generuje wartość code verifier, wysyła do serwera jej przekształcenie jako code challenge, a następnie przedstawia oryginalny verifier przy wymianie kodu. Utrudnia to wykorzystanie przechwyconego kodu przez inną aplikację.

Tokeny, zakresy i bezpieczeństwo połączenia

Token dostępu jest poświadczeniem pozwalającym wywoływać chronione zasoby w imieniu użytkownika. Przy korzystaniu z tokenu typu Bearer posiadacz tokenu może zostać uznany za uprawnionego, dlatego token nie powinien być ujawniany w adresie URL, logach, historii przeglądarki ani komunikatach diagnostycznych. W żądaniach HTTP token jest zwykle przekazywany w nagłówku Authorization: Bearer token. Specyfikacja OAuth 2.0 Bearer Token Usage jest opisana w RFC 6750. Po wygaśnięciu tokenu aplikacja może użyć tokenu odświeżającego, jeżeli serwer autoryzacyjny wydał go w danym przepływie i zakresie uprawnień.

Zakresy, nazywane scopes, ograniczają rodzaj operacji dostępnych dla klienta. Zakres read może oznaczać odczyt danych, natomiast osobny zakres write może pozwalać na ich modyfikację, jednak konkretne nazwy i znaczenie zakresów ustala dostawca usługi. Adres redirect URI powinien być zarejestrowany i dokładnie sprawdzany, ponieważ przekierowanie kodu na obcą domenę może prowadzić do przejęcia autoryzacji. Połączenia z serwerem autoryzacyjnym i serwerem zasobów powinny być realizowane przez HTTPS. Sekrety klienta nie mogą być umieszczane w kodzie aplikacji mobilnej ani w kodzie JavaScript wysyłanym do przeglądarki, ponieważ użytkownik może je odczytać.

OAuth w praktyce serwisowej

Problemy z logowaniem opartym na OAuth często wynikają z niezgodności adresu przekierowania, błędnego zakresu uprawnień, niewłaściwego czasu systemowego albo zapisania uszkodzonego tokenu w pamięci aplikacji. Objawem może być komunikat invalid_grant, invalid_client, redirect_uri_mismatch lub ciągłe ponawianie logowania. Diagnostyka powinna obejmować sprawdzenie dokładnego adresu callback, konfiguracji klienta u dostawcy usługi, aktualności certyfikatów oraz tego, czy aplikacja poprawnie przechowuje i usuwa tokeny po wylogowaniu. Nie należy kopiować tokenów do zgłoszeń serwisowych ani przesyłać ich osobom prowadzącym diagnostykę.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego przy problemach z aplikacjami korzystającymi z OAuth można rozpocząć od sprawdzenia systemu, przeglądarki, połączenia sieciowego oraz lokalnej konfiguracji programu. Serwisowa diagnostyka może wykazać między innymi nieaktualną przeglądarkę, błędne ustawienia daty i czasu, blokowanie przekierowań przez rozszerzenie albo uszkodzone dane sesji. Sama naprawa komputera nie zmienia uprawnień nadanych aplikacji u zewnętrznego dostawcy; cofnięcie zgody lub unieważnienie tokenów wykonuje się w ustawieniach odpowiedniego konta.