Platforma tożsamości firmy Microsoft i protokół OpenID Connect tożsamości

OpenID Connect (OIDC) to protokół uwierzytelniania zbudowany na protokole OAuth 2.0, który umożliwia bezpieczne logowanie użytkownika do aplikacji. W przypadku korzystania z implementacji platformy tożsamości firmy Microsoft OpenID Connect można dodać do aplikacji dostęp do logowania i interfejsu API. W tym artykule pokazano, jak to zrobić niezależnie od języka, oraz opisano sposób wysyłania i odbierania komunikatów HTTP bez używania jakichkolwiek bibliotek open source firmy Microsoft.

OpenID Connect rozszerza protokół autoryzacji OAuth 2.0 do użycia jako protokół uwierzytelniania, dzięki czemu można zalogować się za pomocą protokołu OAuth. OpenID Connect wprowadza koncepcję tokenu identyfikatora, który jest tokenem zabezpieczającym umożliwiającym klientowi zweryfikowanie tożsamości użytkownika. Token identyfikatora pobiera również podstawowe informacje o profilu użytkownika. Wprowadza również punkt końcowy UserInfo, interfejs API, który zwraca informacje o użytkowniku.

Diagram protokołu: Logowanie

Najbardziej podstawowy przepływ logowania zawiera kroki pokazane na następnym diagramie. Każdy krok został szczegółowo opisany w tym artykule.

OpenID Connect protokołu: Logowanie

Pobieranie dokumentu OpenID Connect metadanych

OpenID Connect opisano dokument metadanych (RFC), który zawiera większość informacji wymaganych przez aplikację do zalogowania się. Obejmuje to informacje, takie jak adresy URL do użycia i lokalizacja publicznych kluczy podpisywania usługi. Ten dokument można znaleźć, dołączając ścieżkę dokumentu odnajdywania do adresu URL urzędu:

Ścieżka dokumentu odnajdywania: /.well-known/openid-configuration

Organ: https://login.microsoftonline.com/{tenant}/v2.0

Może {tenant} przyjmować jedną z czterech wartości:

Wartość Opis
common Użytkownicy z kontami osobistymi konto Microsoft konta służbowego z usługi Azure AD mogą logować się do aplikacji.
organizations Tylko użytkownicy z kontami służbowy z usługi Azure AD mogą logować się do aplikacji.
consumers Tylko użytkownicy z osobistym konto Microsoft mogą logować się do aplikacji.
8eaef023-2b34-4da1-9baa-8bc8c9d6a490 lub contoso.onmicrosoft.com Do aplikacji mogą logować się tylko użytkownicy z określonej dzierżawy usługi Azure AD (niezależnie od tego, czy znajdują się w katalogu z kontem służbowym, czy są gośćmi w katalogu z konto Microsoft). Można użyć przyjaznej nazwy domeny dzierżawy usługi Azure AD lub identyfikatora GUID dzierżawy. Możesz również użyć dzierżawy konsumenta , 9188040d-6c67-4c5b-b112-36a304b66dad w miejsce consumers dzierżawy.

Urząd różni się w różnych chmurach krajowych — np. w przypadku wystąpienia https://login.microsoftonline.de usługi Azure AD w Niemczech. Jeśli nie korzystasz z chmury publicznej, zapoznaj się z punktami końcowymi chmury krajowej, aby znaleźć odpowiedni dla Ciebie. Upewnij się, że dzierżawa i są obecne w żądaniu, aby można było korzystać z wersji /v2.0/ 2.0 punktu końcowego.

Porada

Wypróbuj! Kliknij, https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration aby wyświetlić common konfigurację.

Przykładowe żądanie

Aby wywołać punkt końcowy userinfo dla wspólnego urzędu w chmurze publicznej, użyj następującego polecenia:

GET /common/v2.0/.well-known/openid-configuration
Host: login.microsoftonline.com

Przykładowa odpowiedź

Metadane to prosty JavaScript Object Notation (JSON). Zobacz poniższy fragment kodu, aby uzyskać przykład. Zawartość jest w pełni opisana w OpenID Connect specyfikacji .

{
  "authorization_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize",
  "token_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token",
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "private_key_jwt"
  ],
  "jwks_uri": "https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys",
  "userinfo_endpoint": "https://graph.microsoft.com/oidc/userinfo",
  "subject_types_supported": [
      "pairwise"
  ],
  ...

}

Jeśli aplikacja ma niestandardowe klucze podpisywania w wyniku używania funkcji mapowania oświadczeń, należy dołączyć parametr zapytania zawierający identyfikator aplikacji, aby uzyskać informacje o kluczu podpisywania appid jwks_uri aplikacji. Na przykład: https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e zawiera jwks_uri . https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e

Zazwyczaj ten dokument metadanych jest używany do konfigurowania biblioteki OpenID Connect zestawu SDK. Biblioteka będzie używać metadanych do pracy. Jeśli jednak nie używasz wstępnie sbudowaną biblioteki OpenID Connect, możesz wykonać kroki opisane w dalszej części tego artykułu, aby zalogować się w aplikacji internetowej przy użyciu platformy tożsamości firmy Microsoft.

Wysyłanie żądania logowania

Gdy aplikacja internetowa musi uwierzytelnić użytkownika, może skierować użytkownika do punktu /authorize końcowego. To żądanie jest podobne do pierwszego części przepływu kodu autoryzacji OAuth 2.0z tymi ważnymi różnicami:

  • Żądanie musi zawierać openid zakres w scope parametrze .
  • Parametr response_type musi zawierać wartość id_token .
  • Żądanie musi zawierać nonce parametr .

Ważne

Aby pomyślnie zażądać tokenu identyfikatora z punktu końcowego /authorization, rejestracja aplikacji w portalu rejestracji musi mieć niejawne przyznanie tokenu id_tokens włączone na karcie Uwierzytelnianie (która ustawia flagę w oauth2AllowIdTokenImplicitFlow manifeście aplikacji na true wartość ). Jeśli ta opcja nie jest włączona, zostanie zwrócony błąd: "Podana wartość parametru wejściowego "response_type" jest dozwolona unsupported_response dla tego klienta. Oczekiwana wartość to "code"

Na przykład:

// Line breaks are for legibility only.

GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=form_post
&scope=openid
&state=12345
&nonce=678910
Parametr Warunek Opis
tenant Wymagane Możesz użyć wartości w ścieżce żądania, aby kontrolować, kto {tenant} może zalogować się do aplikacji. Dozwolone wartości to common , organizations , i consumers identyfikatory dzierżawy. Aby uzyskać więcej informacji, zobacz podstawowe informacje o protokole.
client_id Wymagane Identyfikator aplikacji (klienta), który Azure Portal — Rejestracje aplikacji środowisko przypisane do aplikacji.
response_type Wymagane Musi zawierać id_token OpenID Connect logowania. Może również zawierać inne response_type wartości, takie jak code .
redirect_uri Zalecane Adres URI przekierowania aplikacji, w którym aplikacja może wysyłać i odbierać odpowiedzi uwierzytelniania. Musi on być dokładnie taki sam jak jeden z adresów URL przekierowania zarejestrowanych w portalu, z tą różnicą, że musi być zakodowany w adresie URL. Jeśli nie ma go, punkt końcowy wybierze jedną zarejestrowaną redirect_uri losowo, aby odesłać użytkownika.
scope Wymagane Rozdzielana spacjami lista zakresów. Na OpenID Connect musi zawierać zakres , co przekłada się na uprawnienie openid "Zaloguj się" w interfejsie użytkownika wyrażania zgody. Możesz również uwzględnić inne zakresy w tym żądaniu zgody.
nonce Wymagane Wartość uwzględniona w żądaniu wygenerowana przez aplikację, która zostanie uwzględniona w wynikowej id_token jako oświadczenie. Aplikacja może zweryfikować tę wartość, aby ograniczyć ataki na powtarzanie tokenów. Wartość jest zazwyczaj losowym, unikatowym ciągiem, który może służyć do identyfikowania źródła żądania.
response_mode Zalecane Określa metodę, która ma być używana do wysyłania wynikowego kodu autoryzacji z powrotem do aplikacji. Możliwe wartości to form_post i fragment. W przypadku aplikacji internetowych zalecamy użycie polecenia , aby zapewnić response_mode=form_post najbezpieczniejszy transfer tokenów do aplikacji.
state Zalecane Wartość uwzględniona w żądaniu, która również zostanie zwrócona w odpowiedzi tokenu. Może to być ciąg dowolnej zawartości. Losowo wygenerowana unikatowa wartość jest zwykle używana do zapobiegania atakom fałszerczym żądań między witrynami. Stan jest również używany do kodowania informacji o stanie użytkownika w aplikacji przed żądaniem uwierzytelnienia, takich jak strona lub widok, na którym użytkownik był.
prompt Opcjonalne Wskazuje wymagany typ interakcji z użytkownikiem. Jedyne prawidłowe wartości w tej chwili to login , none , i consent select_account . Oświadczenie prompt=login wymusza na użytkowniku wprowadzenie poświadczeń dla tego żądania, co neguje logowanie pojedyncze. Parametr prompt=none jest odwrotny i powinien być sparowany z parametrem , aby wskazać, który użytkownik musi być login_hint zalogowany. Te parametry zapewniają, że użytkownik nie będzie w ogóle wyświetlać żadnego interaktywnego monitu. Jeśli żądania nie można ukończyć w trybie dyskretnym za pośrednictwem logowania pojedynczego (ponieważ żaden użytkownik nie jest zalogowany, użytkownik z wskazówką nie jest zalogowany lub jest zalogowanych wielu użytkowników i nie podano żadnej wskazówki), platforma tożsamości firmy Microsoft zwraca błąd. Oświadczenie prompt=consent wyzwala okno dialogowe zgody OAuth po tym, jak użytkownik się logowania. W oknie dialogowym zostanie wyświetlone pytanie o udzielenie uprawnień do aplikacji. Na koniec program pokazuje użytkownikowi selektor konta, negując dyskretne logowanie jednokrotne, ale umożliwiając użytkownikowi wybranie konta, za pomocą którego zamierza się zalogować, bez konieczności wprowadzania select_account poświadczeń. Nie można używać login_hint razem select_account i .
login_hint Opcjonalne Możesz użyć tego parametru, aby wstępnie wypełnić pole nazwy użytkownika i adresu e-mail na stronie logowania dla użytkownika, jeśli wcześniej znasz nazwę użytkownika. Często aplikacje używają tego parametru podczas ponownego uwierzytelniania po wyodrębnieniu nazwy użytkownika z wcześniejszego logowania przy użyciu preferred_username oświadczenia .
domain_hint Opcjonalne Domenę użytkownika w katalogu federacyjnym. Pozwala to pominąć proces odnajdywania opartego na wiadomościach e-mail, który użytkownik przechodzi na stronie logowania, aby nieco usprawnić środowisko użytkownika. W przypadku dzierżaw, które są federowane za pośrednictwem katalogu lokalnego, takiego jak AD FS, często skutkuje to bezproblemowym logowaniem z powodu istniejącej sesji logowania.

W tym momencie użytkownik jest monitowany o wprowadzenie poświadczeń i ukończenie uwierzytelniania. Platforma tożsamości firmy Microsoft sprawdza, czy użytkownik wyraził zgodę na uprawnienia wskazane w scope parametrze zapytania. Jeśli użytkownik nie wyraził zgody na żadne z tych uprawnień, platforma tożsamości firmy Microsoft monituje użytkownika o wyrażenie zgody na wymagane uprawnienia. Możesz przeczytać więcej na temat uprawnień, zgody i aplikacji wielodostępnych.

Gdy użytkownik uwierzytelnia się i udziela zgody, platforma tożsamości firmy Microsoft zwraca odpowiedź do aplikacji we wskazanym identyfikatorze URI przekierowania przy użyciu metody określonej w response_mode parametrze .

Pomyślna odpowiedź

Po pomyślnym użyciu odpowiedzi response_mode=form_post wygląda następująco:

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&state=12345
Parametr Opis
id_token Token identyfikatora żądany przez aplikację. Możesz użyć parametru , aby zweryfikować tożsamość użytkownika i id_token rozpocząć sesję z użytkownikiem. Aby uzyskać więcej informacji na temat tokenów identyfikatorów i ich zawartości, zobacz id_tokens odwołanie.
state Jeśli parametr state jest uwzględniony w żądaniu, ta sama wartość powinna pojawić się w odpowiedzi. Aplikacja powinna sprawdzić, czy wartości stanu w żądaniu i odpowiedzi są identyczne.

Odpowiedź z błędem

Odpowiedzi na błędy mogą być również wysyłane do przekierowania URI, aby aplikacja mogła je obsłużyć. Odpowiedź na komunikat o błędzie wygląda następująco:

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

error=access_denied&error_description=the+user+canceled+the+authentication
Parametr Opis
error Ciąg kodu błędu, który umożliwia klasyfikowanie typów błędów, które wystąpią, i reagowanie na błędy.
error_description Określony komunikat o błędzie, który może pomóc w zidentyfikowaniu głównej przyczyny błędu uwierzytelniania.

Kody błędów dla błędów punktu końcowego autoryzacji

W poniższej tabeli opisano kody błędów, które mogą być zwracane w error parametrze odpowiedzi błędu:

Kod błędu Opis Akcja klienta
invalid_request Błąd protokołu, taki jak brakujący, wymagany parametr. Napraw i prześlij ponownie żądanie. Jest to błąd programistyki, który zwykle jest przechwycony podczas wstępnego testowania.
unauthorized_client Aplikacja kliency nie może zażądać kodu autoryzacji. Dzieje się tak zwykle, gdy aplikacja kliencyjna nie jest zarejestrowana w usłudze Azure AD lub nie została dodana do dzierżawy usługi Azure AD użytkownika. Aplikacja może monitować użytkownika o instrukcje dotyczące instalowania aplikacji i dodawania jej do usługi Azure AD.
access_denied Właściciel zasobu odrzucił zgodę. Aplikacja kliency może powiadomić użytkownika, że nie może kontynuować pracy, chyba że użytkownik na to zgotuje.
unsupported_response_type Serwer autoryzacji nie obsługuje typu odpowiedzi w żądaniu. Napraw i prześlij ponownie żądanie. Jest to błąd programistyki, który zwykle jest przechwycony podczas wstępnego testowania.
server_error Serwer napotkał nieoczekiwany błąd. Ponów próbę żądania. Te błędy mogą wynikać z warunków tymczasowych. Aplikacja kliency może wyjaśnić użytkownikowi, że jej odpowiedź jest opóźniona z powodu tymczasowego błędu.
temporarily_unavailable Serwer jest tymczasowo zbyt zajęty, aby obsłużyć żądanie. Ponów próbę żądania. Aplikacja kliency może wyjaśnić użytkownikowi, że jej odpowiedź jest opóźniona z powodu tymczasowego warunku.
invalid_resource Zasób docelowy jest nieprawidłowy, ponieważ nie istnieje, usługa Azure AD nie może go znaleźć lub nie jest poprawnie skonfigurowana. Oznacza to, że zasób, jeśli istnieje, nie został skonfigurowany w dzierżawie. Aplikacja może monitować użytkownika o instrukcje dotyczące instalowania aplikacji i dodawania jej do usługi Azure AD.

Weryfikowanie tokenu identyfikatora

Samo odebranie id_token nie zawsze wystarczy do uwierzytelnienia użytkownika. Może być również konieczne zweryfikowanie podpisu id_token i zweryfikowanie oświadczeń w tokenie zgodnie z wymaganiami aplikacji. Podobnie jak wszystkie platformy OIDC, platforma tożsamości firmy Microsoft używa tokenów sieci Web JSON (JWTs) i kryptografii klucza publicznego do podpisywania tokenów identyfikatorów i weryfikowania ich ważności.

Nie wszystkie aplikacje mogą na przykład weryfikować token identyfikatora — aplikacje natywne i aplikacje jednostronicowe rzadko korzystają z weryfikacji tokenu identyfikatora. Osoba mająca fizyczny dostęp do urządzenia (lub przeglądarki) może pominąć weryfikację na wiele sposobów — od edytowania ruchu internetowego do urządzenia w celu zapewnienia fałszywych tokenów i kluczy po proste debugowanie aplikacji w celu pominięcia logiki weryfikacji. Z drugiej strony aplikacje internetowe i interfejsy API używające tokenu identyfikatora do autoryzacji muszą dokładnie zweryfikować token identyfikatora, ponieważ mają dostęp do danych.

Po zweryfikowaniu podpisu id_token należy zweryfikować kilka oświadczeń. Zapoznaj się z id_token odwołaniem, aby uzyskać więcej informacji, w tym na temat sprawdzania poprawności tokenów i ważnych informacji na temat przechwycania klucza podpisywania. Zalecamy korzystanie z biblioteki do analizowania i sprawdzania tokenów — dla większości języków i platform jest dostępny co najmniej jeden.

Możesz również sprawdzić poprawność dodatkowych oświadczeń w zależności od scenariusza. Niektóre typowe weryfikacje obejmują:

  • Upewnienie się, że użytkownik/organizacja zapisano aplikację.
  • Upewnienie się, że użytkownik ma odpowiednią autoryzację/uprawnienia
  • Upewnienie się, że wystąpiła pewna siła uwierzytelniania, na przykład uwierzytelnianie wieloskładnikowe.

Po weryfikacji id_token możesz rozpocząć sesję z użytkownikiem i użyć oświadczeń w id_token, aby uzyskać informacje o użytkowniku w aplikacji. Te informacje mogą służyć do wyświetlania, rekordów, personalizacji itp.

Diagram protokołu: Uzyskiwanie tokenu dostępu

Wiele aplikacji internetowych musi nie tylko zalogować użytkownika, ale także uzyskać dostęp do usługi internetowej w imieniu użytkownika przy użyciu protokołu OAuth. Ten scenariusz łączy OpenID Connect uwierzytelniania użytkowników przy równoczesnym uzyskiwaniu kodu autoryzacji, który umożliwia uzyskanie tokenów dostępu, jeśli używasz przepływu kodu autoryzacji OAuth.

Pełny przepływ OpenID Connect logowania i pozyskiwania tokenu wygląda podobnie do następnego diagramu. Poszczególne kroki opisano szczegółowo w kolejnych sekcjach artykułu.

OpenID Connect protokołu: Pozyskiwanie tokenu

Uzyskiwanie tokenu dostępu w celu wywołania informacji o użytkowniku

Aby uzyskać token dla punktu końcowego OIDC UserInfo, zmodyfikuj żądanie logowania:

// Line breaks are for legibility only.

GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e        // Your registered Application ID
&response_type=id_token%20token                       // this will return both an id_token and an access token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F       // Your registered redirect URI, URL encoded
&response_mode=form_post                              // 'form_post' or 'fragment'
&scope=openid+profile+email                           // `openid` is required.  `profile` and `email` provide additional information in the UserInfo endpoint the same way they do in an ID token. 
&state=12345                                          // Any value, provided by your app
&nonce=678910                                         // Any value, provided by your app

Możesz również użyć przepływu koduautoryzacji, przepływu kodu urządzenia lub tokenu odświeżania, aby uzyskać token dla response_type=token aplikacji.

Porada

Kliknij poniższy link, aby wykonać to żądanie. Po zalogowaniu przeglądarka zostanie przekierowana do strony z tokenem identyfikatora https://localhost/myapp/ i tokenem na pasku adresu. Należy pamiętać, że to żądanie jest używane tylko w celach demonstracyjnych — w przypadku aplikacji internetowej zalecamy użycie tej aplikacji w celu zastosowania dodatkowych response_mode=fragment form_post zabezpieczeń, jeśli jest to możliwe. https://login.microsoftonline.com/common/oauth2/v2.0/authorize...

Pomyślna odpowiedź tokenu

Po pomyślnym użyciu odpowiedzi response_mode=form_post wygląda następująco:

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
 access_token=eyJ0eXAiOiJKV1QiLCJub25jZSI6I....
 &token_type=Bearer
 &expires_in=3598
 &scope=email+openid+profile
 &id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI....
 &state=12345

Parametry odpowiedzi oznaczają to samo niezależnie od przepływu użytego do ich uzyskania.

Parametr Opis
access_token Token, który będzie używany do wywołania punktu końcowego UserInfo.
token_type Zawsze "Bearer"
expires_in Czas wygaśnięcia tokenu dostępu (w sekundach).
scope Uprawnienia przyznane dla tokenu dostępu. Należy pamiętać, że ponieważ punkt końcowy UserInfo jest hostowany w programie MS Graph, w tym miejscu mogą być wymienione dodatkowe zakresy programu Graph (np. user.read), jeśli zostały one wcześniej przyznane aplikacji. Wynika to z tego, że token dla danego zasobu zawsze obejmuje każde uprawnienie aktualnie przyznane klientowi.
id_token Token identyfikatora żądany przez aplikację. Token identyfikatora umożliwia zweryfikowanie tożsamości użytkownika i rozpoczęcie sesji z użytkownikiem. Więcej szczegółów na temat tokenów identyfikatorów i ich zawartości można znaleźć w id_tokens odwołaniach.
state Jeśli parametr stanu jest uwzględniony w żądaniu, ta sama wartość powinna pojawić się w odpowiedzi. Aplikacja powinna sprawdzić, czy wartości stanu w żądaniu i odpowiedzi są identyczne.

Odpowiedź z błędem

Odpowiedzi na błędy mogą być również wysyłane do przekierowania URI, aby aplikacja mogła je odpowiednio obsłużyć. Odpowiedź na komunikat o błędzie wygląda następująco:

POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

error=access_denied&error_description=the+user+canceled+the+authentication
Parametr Opis
error Ciąg kodu błędu, który umożliwia klasyfikowanie typów błędów, które wystąpią, i reagowanie na błędy.
error_description Określony komunikat o błędzie, który może pomóc w zidentyfikowaniu głównej przyczyny błędu uwierzytelniania.

Opis możliwych kodów błędów i zalecanych odpowiedzi klientów zawiera temat Kody błędów dla błędów punktu końcowego autoryzacji.

Jeśli masz kod autoryzacji i token identyfikatora, możesz zalogować użytkownika i uzyskać tokeny dostępu w jego imieniu. Aby zalogować użytkownika, należy zweryfikować token identyfikatora dokładnie zgodnie z opisem. Aby uzyskać tokeny dostępu, wykonaj kroki opisane w dokumentacji przepływu kodu OAuth.

Wywoływanie punktu końcowego UserInfo

Przejrzyj dokumentację UserInfo, aby sprawdzić, jak wywołać punkt końcowy UserInfo przy użyciu tego tokenu.

Wysyłanie żądania wylogowania

Jeśli chcesz wylogować użytkownika z aplikacji, nie wystarczy wyczyścić pliki cookie aplikacji ani w inny sposób zakończyć sesję użytkownika. Należy również przekierować użytkownika do platformy tożsamości firmy Microsoft w celu wylogowania się. Jeśli tego nie zrobisz, użytkownik ponownie uwierzytelnia się w aplikacji bez ponownego wprowadzania poświadczeń, ponieważ będzie miał prawidłową sesję logowania pojedynczego z platformą tożsamości firmy Microsoft.

Możesz przekierować użytkownika do elementu end_session_endpoint wymienionego w dokumencie OpenID Connect metadanych:

GET https://login.microsoftonline.com/common/oauth2/v2.0/logout?
post_logout_redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
Parametr Warunek Opis
post_logout_redirect_uri Zalecane Adres URL, do który użytkownik jest przekierowywany po pomyślnym wylogowaniu. Jeśli parametr nie zostanie uwzględniony, użytkownikowi zostanie wyświetlony ogólny komunikat wygenerowany przez platformę tożsamości firmy Microsoft. Ten adres URL musi odpowiadać jednem z adresów URD przekierowania zarejestrowanym dla Twojej aplikacji w portalu rejestracji aplikacji.

Wylogowanie jednokrotne

Po przekierowaniu użytkownika do usługi platforma tożsamości firmy Microsoft wyczyści end_session_endpoint jego sesję z przeglądarki. Jednak użytkownik może być nadal zalogowany do innych aplikacji, które używają kont Microsoft do uwierzytelniania. Aby umożliwić tym aplikacjom jednoczesne wylogowanie użytkownika, platforma tożsamości firmy Microsoft wysyła żądanie HTTP GET do zarejestrowanej wszystkich aplikacji, do których użytkownik jest LogoutUrl obecnie zalogowany. Aplikacje muszą odpowiedzieć na to żądanie, czyszcząc każdą sesję, która identyfikuje użytkownika, i zwracając 200 odpowiedź. Jeśli chcesz obsługiwać logowanie pojedyncze w aplikacji, musisz zaimplementować taki kod w LogoutUrl kodzie aplikacji. Możesz ustawić wartość LogoutUrl w portalu rejestracji aplikacji.

Następne kroki