uwierzytelnianie OAuth2

Uwierzytelnianie OAuth2 to obowiązująca wersja tego standardu, wymagana obecnie przez większość dostawców poczty.

OAuth 2.0 jako sposób nadawania dostępu aplikacji

Uwierzytelnianie OAuth2, częściej zapisywane jako OAuth 2.0, jest standardem delegowania dostępu do zasobów użytkownika bez przekazywania aplikacji jego hasła. W praktyce aplikacja pocztowa, kalendarz, program do zarządzania plikami albo klient komunikatora może uzyskać ograniczone uprawnienia do konta w usłudze zewnętrznego dostawcy. Użytkownik loguje się bezpośrednio na stronie tego dostawcy, akceptuje określony zakres dostępu, a następnie aplikacja otrzymuje token. Hasło pozostaje po stronie dostawcy tożsamości i nie jest wpisywane do konfiguracji programu.

OAuth 2.0 nie jest pojedynczym mechanizmem logowania, lecz strukturą opisaną w dokumencie RFC 6749. Standard rozdziela kilka ról: właściciela zasobu, klienta, serwer autoryzacji oraz serwer zasobu. Właściciel zasobu podejmuje decyzję o zgodzie, klientem jest aplikacja żądająca dostępu, serwer autoryzacji wydaje tokeny, a serwer zasobu udostępnia chronione dane. W typowym scenariuszu pocztowym serwer zasobu może obsługiwać skrzynkę za pomocą protokołu IMAP lub SMTP, natomiast serwer autoryzacji prowadzi logowanie i wydaje poświadczenia dla programu pocztowego.

Token dostępu, zakres uprawnień i odświeżanie sesji

Najważniejszym rezultatem przepływu OAuth2 jest access token, czyli token dostępu. Aplikacja przekazuje go później do serwera zasobu zamiast hasła, zwykle w nagłówku HTTP Authorization z typem Bearer. Token typu Bearer należy traktować jak czasowe poświadczenie, ponieważ osoba lub program posiadający taki token może wykorzystać go w zakresie przewidzianym przez dostawcę. Dlatego token nie powinien trafiać do logów, komunikatów diagnostycznych, zrzutów ekranu ani plików udostępnianych innym osobom.

Dostęp jest ograniczany przez scope, czyli zakres uprawnień. Zakres może dotyczyć na przykład odczytu wiadomości, wysyłania poczty albo dostępu do określonej usługi. Konkretne nazwy zakresów nie są uniwersalne dla wszystkich dostawców, dlatego aplikacja musi korzystać z wartości wymaganych przez daną usługę. Access token ma zwykle ograniczony czas ważności. Aby użytkownik nie musiał przeprowadzać pełnego logowania przy każdym uruchomieniu programu, dostawca może wydać refresh token. Służy on do uzyskania kolejnego access tokenu, ale nie zastępuje go bezpośrednio przy każdym żądaniu do serwera zasobu. Sposób ważności, unieważniania i rotacji refresh tokenów zależy od polityki dostawcy.

Authorization Code i bezpieczna konfiguracja klienta

W aplikacjach działających na laptopie lub komputerze PC najczęściej stosuje się przepływ Authorization Code. Program kieruje użytkownika do serwera autoryzacji, a po poprawnym logowaniu i wyrażeniu zgody otrzymuje kod autoryzacyjny. Kod ten jest następnie wymieniany na tokeny. Sam kod jest krótkotrwały i jednorazowy, dzięki czemu jego przechwycenie jest mniej użyteczne niż przechwycenie długotrwałego tokenu. Współczesne aplikacje powinny stosować także PKCE, opisane w RFC 7636. Mechanizm ten wiąże żądanie autoryzacji z późniejszą wymianą kodu za pomocą losowego verifiera, co ogranicza ryzyko wykorzystania kodu przez nieuprawnioną aplikację.

Klient publiczny, taki jak aplikacja instalowana na komputerze użytkownika, nie może bezpiecznie przechowywać sekretu w sposób właściwy dla serwera. W związku z tym nie należy traktować wpisanego w programie client secret jako pełnej ochrony. Konfiguracja musi zawierać prawidłowy identyfikator klienta, adresy przekierowania oraz zakresy zaakceptowane przez dostawcę. Redirect URI, czyli adres powrotu po logowaniu, powinien odpowiadać wartości zarejestrowanej u dostawcy. Nawet drobna różnica w schemacie, porcie, ścieżce lub nazwie hosta może spowodować odrzucenie żądania. W aplikacjach desktopowych spotyka się przekierowanie do lokalnego serwera nasłuchującego na porcie wskazanym przez program albo do specjalnego schematu URI obsługiwanego przez aplikację.

Objawy problemów z OAuth2 w programie pocztowym

Błąd OAuth2 może pojawić się mimo poprawnego hasła do skrzynki. Przyczyną bywa wygasły access token, unieważniony refresh token, brak wymaganego zakresu, niezgodny redirect URI, nieprawidłowa data i godzina systemowa albo przestarzały klient, który nie obsługuje wymaganego przepływu autoryzacji. Użytkownik może zobaczyć ponowne żądanie logowania, komunikat o odmowie dostępu, błąd „invalid_grant”, „invalid_client” lub informację, że aplikacja nie ma uprawnień do usługi. W przypadku poczty trzeba odróżnić logowanie do interfejsu webowego od autoryzacji konkretnego klienta IMAP lub SMTP. Sukces w przeglądarce nie gwarantuje, że lokalny program ma właściwy token i odpowiednie scope.

Diagnostyka powinna rozpocząć się od ustalenia, który element nie działa: otwarcie strony logowania, przekierowanie do aplikacji, wymiana kodu, odświeżenie tokenu czy późniejsze połączenie z serwerem pocztowym. Należy sprawdzić wersję programu, ustawiony typ uwierzytelniania, adres serwera, port, szyfrowanie TLS oraz komunikat zwracany przez dostawcę. Nie powinno się kopiować tokenów ani haseł do zgłoszenia serwisowego. Bezpieczniejszym działaniem jest usunięcie zapisanej autoryzacji z aplikacji, ponowne uruchomienie oficjalnego procesu zgody i sprawdzenie, czy konto pozwala na dostęp dla danego klienta. Jeżeli problem dotyczy samego laptopa, systemu, przeglądarki lub programu pocztowego, Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów.