Zła konfiguracja OpenID Connect uniemożliwia poprawne uwierzytelnienie użytkownika w chronionej usłudze.
Jak rozpoznać błędną konfigurację OpenID Connect
Zła konfiguracja OpenID Connect oznacza, że aplikacja korzystająca z logowania nie ma spójnych ustawień z dostawcą tożsamości. OpenID Connect działa jako warstwa uwierzytelniania oparta na OAuth 2.0. Aplikacja, nazywana klientem, przekierowuje użytkownika do dostawcy tożsamości, a po pomyślnym logowaniu otrzymuje kod autoryzacyjny. Kod jest następnie wymieniany na tokeny, w tym na ID token zawierający informacje o uwierzytelnionym użytkowniku.
Typowym objawem jest powrót do aplikacji z komunikatem invalid_redirect_uri, unauthorized_client, invalid_client albo invalid_scope. Błąd może wystąpić również wtedy, gdy logowanie u dostawcy przebiegnie poprawnie, lecz aplikacja odrzuci odpowiedź z powodu niezgodnego wystawcy tokenu, odbiorcy tokenu, podpisu, czasu ważności lub wymaganych roszczeń. Sam ekran logowania nie potwierdza więc, że cały przepływ OpenID Connect został skonfigurowany prawidłowo.
Adresy, identyfikatory i dokument discovery
Jednym z najczęstszych problemów jest różnica między adresem issuer zapisanym w konfiguracji klienta a adresem użytym przez dostawcę tożsamości. Wartość issuer identyfikuje konkretną instancję dostawcy i jest również porównywana z roszczeniem iss w tokenie. Różnica w schemacie http i https, nazwie hosta, porcie, ścieżce albo końcowym ukośniku może spowodować odrzucenie tokenu, nawet jeżeli adres prowadzi do tego samego serwera.
Klient powinien pobierać punkty końcowe z dokumentu OpenID Connect Discovery dostępnego zwykle pod ścieżką /.well-known/openid-configuration względem adresu dostawcy. Dokument ten określa między innymi authorization_endpoint, token_endpoint, userinfo_endpoint oraz jwks_uri. Nieprawidłowo wpisany adres bazowy może skierować aplikację do innego środowiska, na przykład testowego zamiast produkcyjnego, albo do nieistniejącego punktu końcowego.
Adres redirect_uri przekazywany podczas autoryzacji musi odpowiadać adresowi zarejestrowanemu u dostawcy tożsamości. Weryfikacja jest zwykle dokładna, dlatego znaczenie może mieć protokół, subdomena, numer portu, wielkość liter oraz obecność końcowego ukośnika. Aplikacja działająca za odwrotnym proxy może dodatkowo błędnie rozpoznawać własny protokół jako http, mimo że użytkownik korzysta z https. W takiej sytuacji generuje nieprawidłowy adres powrotu.
Walidacja kodu, tokenów i parametrów sesji
W przepływie Authorization Code klient musi używać właściwego client_id, a w przypadku klienta poufnego także poprawnego sekretu klienta. Sekret należy przekazać do punktu końcowego tokenów zgodnie z metodą uwierzytelniania określoną przez dostawcę. Pomieszanie uwierzytelniania przez nagłówek HTTP Basic z przekazaniem danych w treści żądania może zakończyć się błędem invalid_client. Kod autoryzacyjny jest krótkotrwały i jednorazowy; ponowne wysłanie tego samego kodu nie jest prawidłowym sposobem odświeżenia sesji.
W żądaniu zakresów powinien znajdować się zakres openid. Bez niego żądanie jest żądaniem OAuth 2.0, ale nie musi uruchamiać uwierzytelniania OpenID Connect ani zwracać ID token. Zakresy profile i email mogą powodować udostępnienie dodatkowych roszczeń, lecz ich dostępność zależy od konfiguracji dostawcy. Aplikacja nie powinna zakładać, że każde roszczenie będzie obecne, ani traktować dowolnej wartości z tokenu dostępu jako potwierdzenia tożsamości.
ID token musi być sprawdzony przed utworzeniem sesji użytkownika. Walidacja obejmuje co najmniej podpis przy użyciu kluczy opublikowanych pod jwks_uri, zgodność iss z oczekiwanym wystawcą oraz zgodność aud z identyfikatorem klienta. Należy również uwzględnić czasowe roszczenia exp i iat, a w odpowiednich przepływach także nonce. Odrzucenie tokenu z nieznanym algorytmem, niepasującym odbiorcą lub wygasłym terminem jest prawidłowym zachowaniem bezpieczeństwa, a nie usterką samego logowania.
Metodyka sprawdzenia konfiguracji w praktyce
Diagnostykę warto rozpocząć od porównania konfiguracji po obu stronach: adresu wystawcy, identyfikatora klienta, dozwolonych adresów powrotu, zakresów, metody odpowiedzi oraz używanego przepływu. Następnie należy prześledzić pojedynczą próbę logowania od przekierowania do punktu autoryzacji, przez powrót z parametrem code, aż do żądania punktu tokenów. Pomocne są znaczniki czasu, nazwa środowiska i identyfikator korelacyjny, ale w logach nie powinny być zapisywane sekrety klienta, tokeny ani kody autoryzacyjne.
Jeżeli błąd pojawia się po powrocie do aplikacji, trzeba sprawdzić dokładną wartość state oraz relację między wartością wysłaną a odebraną. Parametr state służy do powiązania odpowiedzi z rozpoczętą sesją i ochrony przed nieoczekiwanym żądaniem. W przepływach wymagających nonce aplikacja powinna porównać go z wartością zapisaną przed przekierowaniem. Przy użyciu PKCE klient generuje code_verifier, wysyła odpowiadający mu code_challenge, a później przekazuje pierwotny weryfikator do punktu tokenów; niespójność tych wartości uniemożliwia wymianę kodu.
Na komputerze użytkownika należy dodatkowo sprawdzić, czy zegar systemowy ma poprawną datę i godzinę, czy przeglądarka może zapisać wymagane dane sesyjne oraz czy lokalny program zabezpieczający nie modyfikuje połączenia TLS lub przekierowań. W środowisku firmowym znaczenie mogą mieć także proxy, filtr DNS i reguły zapory, ale ich obecność nie zmienia wymagań protokołu. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, a przy problemach z logowaniem może pomóc rozdzielić usterkę systemu lub sieci lokalnej od błędu konfiguracji dostawcy OpenID Connect.
