Odkrywanie konfiguracji OpenID Connect: Kluczowe pola i ich zastosowania

We współczesnym cyfrowym świecie uwierzytelnianie stało się centralnym elementem zabezpieczania stron internetowych i aplikacji. OpenID Connect (OIDC), warstwa uwierzytelniania zbudowana na protokole OAuth 2.0, oferuje znormalizowany i prosty sposób uwierzytelniania tożsamości.

Jednak prawidłowa integracja OIDC może być trudnym zadaniem, szczególnie dla nowicjuszy. Dobrym punktem początkowym często jest plik konfiguracyjny OIDC, zwykle znajdujący się pod adresem URL {authServerUrl}/.well-known/openid-configuration, który zawiera wszystkie niezbędne szczegóły do wdrożenia usług OIDC.

Ten przewodnik ma na celu wyjaśnienie kluczowych pól w ramach tej konfiguracji, pomagając programistom zrozumieć ich wagę i praktyczne zastosowania, aby lepiej zintegrować OIDC w swoich projektach.

Analiza pól konfiguracyjnych OIDC#

Konfiguracja OIDC to plik JSON podobny do poniższego:

Następnie zagłębimy się w niektóre z kluczowych pól.

authorization_endpoint#

Podczas integracji usług OIDC, pierwszym krokiem zwykle jest obsługa żądań logowania użytkownika w aplikacji. Proces ten obejmuje przekierowanie użytkowników na authorization_endpoint serwera autoryzacji. Ten punkt końcowy to adres serwera, na który wysyłane są żądania autoryzacji, prowadzący użytkowników na stronę logowania w celu uwierzytelnienia.

Podczas składania żądania do authorization_endpoint należy skonfigurować dodatkowe parametry zapytania dla każdej autoryzacji:

• response_type: Określa rodzaj zwracanej autoryzacji. Zazwyczaj zawiera "code" (dla przepływu kodu autoryzacyjnego), "token" (dla przepływu implicit) oraz "id_token token" lub "code id_token" (dla przepływu hybrydowego), które można znaleźć w polu response_types_supported konfiguracji OIDC.
• client_id: Unikalny identyfikator przypisany aplikacji przez serwer autoryzacji podczas rejestracji aplikacji. Ten identyfikator jest używany przez serwer autoryzacji do rozpoznania aplikacji klienckiej inicjującej żądanie.
• scope: Definiuje żądany zakres dostępu, określając zasoby lub informacje użytkownika dostępne. Wspólne zakresy obejmują "openid" (obowiązkowy), "profile" i "email" oraz inne. Możesz znaleźć obsługiwane zakresy w polu scopes_supported konfiguracji OIDC; różne zakresy powinny być oddzielone spacjami.
• redirect_uri: Po zalogowaniu lub autoryzacji serwer autoryzacyjny przekierowuje użytkownika z powrotem na URI podane przez aplikację. Ten URI musi ściśle pasować do URI podanego podczas rejestracji aplikacji.
• state: Losowo wygenerowany ciąg znaków używany do ochrony aplikacji klienckiej przed atakami typu cross-site request forgery (CSRF). Spójność parametru state między żądaniem autoryzacyjnym a callbackiem musi być utrzymana w celu zapewnienia bezpieczeństwa.

Te parametry umożliwiają programistom precyzyjne sterowanie zachowaniem żądań autoryzacyjnych OIDC, zapewniając ich bezpieczeństwo i spełnianie wymagań aplikacji.

Po zakończeniu żądania do authorization_endpoint i przejściu przez uwierzytelnienie użytkownicy są przekierowywani na określony redirect_uri, który będzie zawierał bardzo ważny parametr zapytania—code. Kod autoryzacyjny jest dostarczany przez serwer autoryzacyjny i jest wynikiem tego, że użytkownik uwierzytelnił się i autoryzował aplikację do dostępu do ich informacji na serwerze autoryzacyjnym.

token_endpoint#

token_endpoint to punkt końcowy serwera wykorzystywany przez serwer autoryzacyjny do wymiany wspomnianego kodu autoryzacyjnego na tokeny dostępu oraz odświeżenia. W przepływie OAuth 2.0 z kodem autoryzacyjnym, ten krok jest kluczowy, ponieważ polega na przekształceniu uzyskanego kodu autoryzacyjnego w faktyczne tokeny dostępu, które aplikacja może wykorzystać do uzyskania dostępu do chronionych zasobów użytkownika.

Oto, w jaki sposób wdraża się wymianę kodu autoryzacyjnego na tokeny dostępu (zwróć uwagę, że ten przykład wykorzystuje metodę uwierzytelnienia client_secret_post. Aby uzyskać inne obsługiwane metody uwierzytelnienia, zapoznaj się z późniejszą analizą pola

):

W tym kodzie najpierw wysyłamy żądanie do token_endpoint przy użyciu metody POST. Typ treści jest ustawiony na application/x-www-form-urlencoded, co jest wymagane przez większość serwerów autoryzacyjnych. Ciało żądania zawiera następujące parametry:

• code: Kod autoryzacyjny uzyskany od serwera autoryzacyjnego, który jest zwracany poprzez redirectUri po tym, jak użytkownik zakończy autoryzację.
• redirect_uri: Ten sam URI przekierowania użyty do uzyskania kodu autoryzacyjnego, używany do weryfikacji prawomocności żądania.
• client_id: Identyfikator aplikacji klienckiej, używany do rozpoznania aplikacji składającej żądanie.
• client_secret: Sekret klienta aplikacji, używany do weryfikacji tożsamości aplikacji.
• grant_type: Określa rodzaj autoryzacji, używane jest tutaj "authorization_code", co wskazuje, że token dostępu jest uzyskiwany za pomocą kodu autoryzacyjnego.

Ta funkcja wykonywana jest asynchronicznie i zwraca obiekt JSON zawierający token dostępu, który aplikacja może wykorzystać do żądania danych użytkownika lub wykonywania innych operacji.

userinfo_endpoint#

userinfo_endpoint to punkt końcowy serwera wykorzystywany przez serwer autoryzacyjny do uzyskania szczegółowych informacji o uwierzytelnionych użytkownikach. Po pomyślnym autoryzowaniu użytkowników i uzyskaniu tokenów dostępu przez token_endpoint, aplikacja może żądać tego punktu końcowego, aby uzyskać informacje profilowe użytkownika, takie jak nazwa użytkownika i adres e-mail. Konkretne informacje uzyskane zależą od scope określonego przez użytkownika w żądaniu uwierzytelnienia.

W tej funkcji najpierw używamy metody GET do żądania userinfo_endpoint, włączając pole Authorization w nagłówku żądania, złożone z token_type i accessToken. Jest to standardowa operacja zgodnie ze specyfikacją OAuth 2.0, zapewniająca bezpieczne uzyskiwanie informacji o użytkowniku. Ponadto zakres informacji o użytkowniku uzyskiwanych przez token dostępu zależy całkowicie od wartości parametru scope przyjętych przez użytkownika podczas inicjacji autoryzacji. Na przykład, jeżeli zostanie użyty zakres email, odpowiedź powinna zawierać adres e-mail użytkownika.

issuer & jwks_uri#

Issuer identyfikuje URL serwera autoryzacyjnego, podczas gdy jwks_uri dostarcza URI dla JSON Web Key Set (JWKS), który jest zestawem kluczy publicznych używanych do weryfikacji podpisów JWT. Weryfikacja issuer i podpisu JWT to podstawowe kroki w zapewnianiu bezpieczeństwa tokenów, ale w rzeczywistych

scenariuszach proces weryfikacji zazwyczaj obejmuje również sprawdzenie okresu ważności tokena, odbiorcy, zakresu autoryzacji i innych ważnych pól.

Poniższy kod przede wszystkim pokazuje, jak używać issuer i jwks_uri razem do weryfikacji JWT:

scopes_supported & claims_supported#

Pola claims_supported i scopes_supported deklarują atrybuty użytkownika (claims) i zakresy dostępu (scopes) wspierane przez serwer autoryzacyjny. Pomagają one klientom zrozumieć, które atrybuty użytkownika i zakresy dostępu są obsługiwane przez serwer autoryzacyjny, umożliwiając klientom efektywne tworzenie żądań autoryzacyjnych i analizowanie odpowiedzi.

Podczas tworzenia żądania autoryzacyjnego klienci mogą określić wymagany scope na podstawie potrzeb aplikacji. Zakres określa zasoby i operacje, do których klient chce uzyskać dostęp, takie jak openid, email, profile i inne.

Należy pamiętać, że konkretne atrybuty użytkownika dostępne w każdym żądaniu autoryzacyjnym różnią się w zależności od wartości scope określonych na początku żądania uwierzytelnienia. Na przykład, zakres email zapewnia dostęp do adresu e-mail użytkownika, podczas gdy zakres phone umożliwia dostęp do jego numeru telefonu. Dlatego klienci powinni starannie dobierać odpowiedni zakres, aby spełnić potrzeby aplikacji podczas tworzenia żądania autoryzacji, zapewniając możliwość uzyskania potrzebnych atrybutów użytkownika:

token_endpoint_auth_methods_supported

#

Pole

wskazuje metody uwierzytelniania obsługiwane przez token endpoint. Te metody są używane przez klienta do uwierzytelniania się w serwerze autoryzacyjnym podczas wymiany kodu autoryzacyjnego na tokeny dostępu.

Podczas uwierzytelniania za pomocą token endpoint, wspólne metody uwierzytelniania obejmują client_secret_post, client_secret_basic oraz client_secret_jwt.

• client_secret_post: Klient używa swojego identyfikatora klienta oraz sekretnu klienta do stworzenia zakodowanego formularza, który jest wysyłany jako część ciała żądania. Już widzieliśmy przykład tej metody w sekcji token_endpoint powyżej.

• client_secret_basic: Klient używa swojego identyfikatora klienta oraz sekretnu klienta do stworzenia nagłówka uwierzytelniania basic, który jest dodawany do nagłówka żądania.

• client_secret_jwt: Klient używa JWT (JSON Web Token) jako asercji klienta do uwierzytelniania. Ten JWT zawiera identyfikator klienta i dodatkowe metadata, i jest podpisany za pomocą sekretnu klienta. Po otrzymaniu żądania serwer autoryzacyjny weryfikuje tożsamość klienta, weryfikując podpis JWT.

W praktycznych zastosowaniach klienci muszą wybrać odpowiednią metodę uwierzytelniania w zależności od metod obsługiwanych przez serwer autoryzacyjny oraz upewnić się, że informacje uwierzytelniające są poprawnie dodane do żądania, aby bezpiecznie wymienić kod autoryzacyjny na tokeny dostępu.

Podsumowanie#

Teraz odkryliśmy kluczowe pola w konfiguracji OIDC, skupiając się na ich celach i zastosowaniach. Zrozumienie tych szczegółów zwiększy Twoją wiedzę na temat OpenID Connect, umożliwiając skuteczniejszą integrację i wykorzystanie go w Twoich projektach. Uzbrojony w tę wiedzę, jesteś lepiej przygotowany do wykorzystania pełnego potencjału OIDC dla bardziej bezpiecznych i efektywnych rozwiązań uwierzytelniania użytkowników.

Logto jako usługa uwierzytelniania oparta na OIDC, która oferuje kompleksowy zestaw SDK w różnych językach wraz z licznymi samouczkami integracyjnymi, umożliwia bezproblemową integrację logowań OAuth / OIDC w Twoich aplikacjach w zaledwie kilka minut. Jeśli szukasz niezawodnej i łatwej w użyciu usługi OIDC, wypróbuj Logto już dziś!