Logowanie jednostronicowe aplikacji przy użyciu niejawnego przepływu OAuth 2.0 w usłudze Azure Active Directory B2C

Wiele nowoczesnych aplikacji ma fronton aplikacji jednostronicowej (SPA), który jest napisany głównie w języku JavaScript. Często aplikacja jest zapisywana przy użyciu platformy, takiej jak React, Angular lub Vue.js. Dodatki SPA i inne aplikacje JavaScript, które działają głównie w przeglądarce, mają pewne dodatkowe wyzwania związane z uwierzytelnianiem:

• Cechy zabezpieczeń tych aplikacji różnią się od tradycyjnych aplikacji internetowych opartych na serwerze.

• Wiele serwerów autoryzacji i dostawców tożsamości nie obsługuje żądań współużytkowania zasobów między źródłami (CORS).

• Przeglądarka pełnostronicowa przekierowuje z dala od aplikacji może być inwazyjna dla środowiska użytkownika.

Zalecanym sposobem obsługi spA jest przepływ kodu autoryzacji OAuth 2.0 (z PKCE).

Niektóre struktury, takie jak MSAL.js 1.x, obsługują tylko niejawny przepływ udzielania. W takich przypadkach usługa Azure Active Directory B2C (Azure AD B2C) obsługuje niejawny przepływ przyznawania autoryzacji OAuth 2.0. Przepływ został opisany w sekcji 4.2 specyfikacji OAuth 2.0. W przepływie niejawnym aplikacja odbiera tokeny bezpośrednio z punktu końcowego autoryzacji usługi Azure AD B2C bez wymiany serwer-serwer. Cała logika uwierzytelniania i obsługa sesji są wykonywane całkowicie w kliencie JavaScript z przekierowania strony lub wyskakującym okienkiem.

Azure AD B2C rozszerza standardowy przepływ niejawny OAuth 2.0 na więcej niż proste uwierzytelnianie i autoryzację. Azure AD B2C wprowadza parametr zasad. Za pomocą parametru zasad można użyć protokołu OAuth 2.0, aby dodać zasady do aplikacji, takie jak przepływy użytkowników rejestracji, logowania i zarządzania profilami. W przykładowym żądaniu HTTP w tym artykule używamy elementu {tenant}.onmicrosoft.com na potrzeby ilustracji. Zastąp {tenant}ciąg nazwą swojej dzierżawy , jeśli masz tę dzierżawę. Ponadto musisz utworzyć przepływ użytkownika.

Użyjemy poniższej ilustracji, aby zilustrować niejawny przepływ logowania. Każdy krok został szczegółowo opisany w dalszej części artykułu.

Wysyłanie żądań uwierzytelniania

Gdy aplikacja internetowa musi uwierzytelnić użytkownika i uruchomić przepływ użytkownika, kieruje użytkownika do punktu końcowego usługi Azure AD B2C/authorize. Użytkownik podejmuje działania w zależności od przepływu użytkownika.

W tym żądaniu klient wskazuje uprawnienia, które musi uzyskać od użytkownika w parametrze scope i przepływ użytkownika do uruchomienia. Aby dowiedzieć się, jak działa żądanie, spróbuj wkleić żądanie w przeglądarce i uruchomić je. Zastąp:

• {tenant}z nazwą dzierżawy usługi Azure AD B2C.

• 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 przy użyciu identyfikatora aplikacji zarejestrowanej w dzierżawie.

• {policy} z nazwą zasad utworzonych w dzierżawie, na przykład b2c_1_sign_in.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345

Parametry w żądaniu HTTP GET zostały wyjaśnione w poniższej tabeli.

Parametr	Wymagane	Opis
{tenant}	Tak	Nazwa dzierżawy usługi Azure AD B2C
{policy}	Tak	Nazwa przepływu użytkownika, który chcesz uruchomić. Określ nazwę przepływu użytkownika utworzonego w dzierżawie usługi Azure AD B2C. Na przykład: b2c_1_sign_in, b2c_1_sign_uplub b2c_1_edit_profile.
client_id	Tak	Identyfikator aplikacji, który Azure Portal przypisany do aplikacji.
response_type	Tak	Musi zawierać id_token dla logowania openID Connect. Może również zawierać typ tokenodpowiedzi . Jeśli używasz usługi token, aplikacja może natychmiast odbierać token dostępu z autoryzowanego punktu końcowego bez konieczności przesyłania drugiego żądania do autoryzowanego punktu końcowego. Jeśli używasz token typu odpowiedzi, parametr musi zawierać zakres wskazujący zasób scope , dla którego ma zostać wystawiony token.
redirect_uri	Nie	Identyfikator URI przekierowania aplikacji, w którym można wysyłać i odbierać odpowiedzi uwierzytelniania przez aplikację. Musi dokładnie odpowiadać jednemu z identyfikatorów URI przekierowania dodanych do zarejestrowanej aplikacji w portalu, z tą różnicą, że musi być zakodowana pod adresem URL.
response_mode	Nie	Określa metodę używaną do wysyłania wynikowego tokenu z powrotem do aplikacji. W przypadku niejawnych przepływów użyj polecenia fragment.
scope	Tak	Rozdzielona spacjami lista zakresów. Pojedyncza wartość zakresu wskazuje Microsoft Entra identyfikatora obu żądanych uprawnień. Zakres openid wskazuje uprawnienia do logowania użytkownika i pobierania danych o użytkowniku w postaci tokenów identyfikatorów. Zakres offline_access jest opcjonalny dla aplikacji internetowych. Wskazuje ona, że aplikacja potrzebuje tokenu odświeżania na potrzeby długotrwałego dostępu do zasobów.
stan	Nie	Wartość uwzględniona w żądaniu, które również jest zwracana w odpowiedzi tokenu. Może to być ciąg dowolnej zawartości, której chcesz użyć. Zazwyczaj jest używana losowo wygenerowana, unikatowa wartość, aby zapobiec atakom fałszowania żądań między witrynami. Stan jest również używany do kodowania informacji o stanie użytkownika w aplikacji przed wystąpieniem żądania uwierzytelnienia, na przykład strony, na którą był użytkownik, lub przepływu użytkownika, który był wykonywany.
nonce	Tak	Wartość uwzględniona w żądaniu (wygenerowanym przez aplikację), która jest uwzględniona w wynikowym tokenie identyfikatora jako oświadczenie. Następnie aplikacja może zweryfikować tę wartość w celu ograniczenia ataków powtarzania tokenu. Zazwyczaj wartość jest losowym, unikatowym ciągiem, który może służyć do identyfikowania źródła żądania.
Wierszu	Nie	Wymagany typ interakcji użytkownika. Obecnie jedyną prawidłową wartością jest login. Ten parametr wymusza na użytkowniku wprowadzenie poświadczeń w ramach tego żądania. Pojedyncze Sign-On nie obowiązują.

Jest to interaktywna część przepływu. Użytkownik jest proszony o ukończenie przepływu pracy zasad. Użytkownik może być musiał wprowadzić swoją nazwę użytkownika i hasło, zalogować się przy użyciu tożsamości społecznościowej, utworzyć konto lokalne lub dowolną inną liczbę kroków. Akcje użytkownika zależą od sposobu definiowania przepływu użytkownika.

Po zakończeniu przepływu użytkownika Azure AD B2C zwraca odpowiedź do aplikacji za pośrednictwem .redirect_uri Używa metody określonej w parametrze response_mode . Odpowiedź jest dokładnie taka sama dla każdego scenariusza akcji użytkownika niezależnie od wykonanego przepływu użytkownika.

Pomyślna odpowiedź

Pomyślna odpowiedź, która używa response_mode=fragment elementów i response_type=id_token+token wygląda następująco, z podziałami wierszy na czytelność:

GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier

Parametr	Opis
access_token	Token dostępu żądany przez aplikację z Azure AD B2C.
token_type	Wartość typu tokenu. Jedynym typem, który obsługuje Azure AD B2C, jest Bearer.
expires_in	Czas ważności tokenu dostępu (w sekundach).
scope	Zakresy, dla których token jest prawidłowy. Możesz również użyć zakresów do buforowania tokenów do późniejszego użycia.
id_token	Token identyfikatora, którego zażądała aplikacja. Możesz użyć tokenu identyfikatora, aby zweryfikować tożsamość użytkownika i rozpocząć sesję z użytkownikiem. Aby uzyskać więcej informacji na temat tokenów identyfikatorów i ich zawartości, zobacz dokumentację Azure AD tokenu B2C.
stan	state Jeśli parametr jest uwzględniony w żądaniu, ta sama wartość powinna pojawić się w odpowiedzi. Aplikacja powinna sprawdzić, czy state wartości w żądaniu i odpowiedzi są identyczne.

Odpowiedź na błąd

Odpowiedzi na błędy można również wysłać do identyfikatora URI przekierowania, aby aplikacja mogła je odpowiednio obsłużyć:

GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response

Parametr	Opis
error	Kod używany do klasyfikowania typów błędów, które występują.
error_description	Określony komunikat o błędzie, który może pomóc zidentyfikować główną przyczynę błędu uwierzytelniania.
stan	state Jeśli parametr jest uwzględniony w żądaniu, ta sama wartość powinna pojawić się w odpowiedzi. Aplikacja powinna sprawdzić, czy state wartości w żądaniu i odpowiedzi są identyczne.

Weryfikowanie tokenu identyfikatora

Odbieranie tokenu identyfikatora nie wystarczy do uwierzytelnienia użytkownika. Zweryfikuj podpis tokenu identyfikatora i zweryfikuj oświadczenia w tokenie zgodnie z wymaganiami aplikacji. Azure AD B2C używa tokenów sieci Web JSON (JWTs) i kryptografii klucza publicznego do podpisywania tokenów i sprawdź, czy są prawidłowe.

Wiele bibliotek typu open source jest dostępnych do walidacji zestawów JWTs, w zależności od języka, którego chcesz użyć. Rozważ eksplorowanie dostępnych bibliotek typu open source zamiast implementowania własnej logiki walidacji. Aby dowiedzieć się, jak prawidłowo korzystać z tych bibliotek, możesz użyć informacji w tym artykule.

Azure AD B2C ma punkt końcowy metadanych OpenID Connect. Aplikacja może używać punktu końcowego do pobierania informacji o Azure AD B2C w czasie wykonywania. Te informacje obejmują punkty końcowe, zawartość tokenu i klucze podpisywania tokenu. Istnieje dokument metadanych JSON dla każdego przepływu użytkownika w dzierżawie usługi Azure AD B2C. Na przykład dokument metadanych przepływu użytkownika o nazwie b2c_1_sign_in w dzierżawie fabrikamb2c.onmicrosoft.com znajduje się pod adresem:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration

Jedną z właściwości tego dokumentu konfiguracji jest jwks_uri. Wartość tego samego przepływu użytkownika to:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys

Aby określić, który przepływ użytkownika został użyty do podpisania tokenu identyfikatora (i miejsca pobierania metadanych), można użyć dowolnej z następujących opcji:

• Nazwa przepływu użytkownika jest uwzględniona w oświadczeniu acr w pliku id_token. Aby uzyskać informacje na temat analizowania oświadczeń z tokenu identyfikatora, zobacz dokumentację tokenu Azure AD B2C.

• Zakoduj przepływ użytkownika w wartości parametru state podczas wystawiania żądania. Następnie zdekoduj state parametr, aby określić, który przepływ użytkownika został użyty.

Po uzyskaniu dokumentu metadanych z punktu końcowego metadanych OpenID Connect można użyć kluczy publicznych RSA-256 (znajdujących się w tym punkcie końcowym), aby zweryfikować podpis tokenu identyfikatora. W tym punkcie końcowym może znajdować się wiele kluczy, z których każda jest identyfikowana przez element kid. Nagłówek zawiera id_token również kid oświadczenie. Wskazuje, które z tych kluczy zostały użyte do podpisania tokenu identyfikatora. Aby uzyskać więcej informacji, w tym informacje na temat weryfikowania tokenów, zobacz dokumentację Azure AD tokenu B2C.

Po zweryfikowaniu podpisu tokenu identyfikatora kilka oświadczeń wymaga weryfikacji. Na przykład:

• Zweryfikuj oświadczenie, nonce aby zapobiec atakom powtarzania tokenu. Jego wartość powinna być określona w żądaniu logowania.

• Zweryfikuj oświadczenie, aud aby upewnić się, że token identyfikatora został wystawiony dla aplikacji. Jego wartość powinna być identyfikatorem aplikacji.

• Zweryfikuj iat oświadczenia i exp , aby upewnić się, że token identyfikatora nie wygasł.

Więcej weryfikacji, które należy wykonać, zostały szczegółowo opisane w specyfikacji OpenID Connect Core. Możesz również zweryfikować dodatkowe oświadczenia w zależności od scenariusza. Niektóre typowe weryfikacje obejmują:

• Upewnienie się, że użytkownik lub organizacja zarejestrowała się w aplikacji.

• Upewnienie się, że użytkownik ma odpowiednie uprawnienia i autoryzację.

• Zapewnienie, że wystąpiła pewna siła uwierzytelniania, na przykład przy użyciu uwierzytelniania wieloskładnikowego Microsoft Entra.

Aby uzyskać więcej informacji na temat oświadczeń w tokenie identyfikatora, zobacz dokumentację Azure AD tokenu B2C.

Po zweryfikowaniu tokenu identyfikatora możesz rozpocząć sesję z użytkownikiem. W aplikacji użyj oświadczeń w tokenie identyfikatora, aby uzyskać informacje o użytkowniku. Te informacje mogą służyć do wyświetlania, rekordów, autoryzacji itd.

Uzyskiwanie tokenów dostępu

Jeśli jedyną rzeczą, jaką musi wykonać aplikacja internetowa, jest wykonywanie przepływów użytkownika, możesz pominąć kilka następnych sekcji. Informacje przedstawione w poniższych sekcjach dotyczą tylko aplikacji internetowych, które muszą wykonywać uwierzytelnione wywołania internetowego interfejsu API chronionego przez samą usługę Azure AD B2C.

Po zalogowaniu użytkownika do SPA możesz uzyskać tokeny dostępu do wywoływania internetowych interfejsów API zabezpieczonych przez identyfikator Microsoft Entra. Nawet jeśli token został już odebrany przy użyciu token typu odpowiedzi, możesz użyć tej metody, aby uzyskać tokeny dla dodatkowych zasobów bez przekierowywania użytkownika do ponownego logowania.

W typowym przepływie aplikacji internetowej należy wysłać żądanie do punktu końcowego /token . Jednak punkt końcowy nie obsługuje żądań CORS, dlatego wykonywanie wywołań AJAX w celu uzyskania tokenu odświeżania nie jest opcją. Zamiast tego możesz użyć niejawnego przepływu w ukrytym elemecie iframe HTML, aby uzyskać nowe tokeny dla innych internetowych interfejsów API. Oto przykład z podziałami wierszy na czytelność:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none

Parametr	Wymagane?	Opis
{tenant}	Wymagane	Nazwa dzierżawy usługi Azure AD B2C
{policy}	Wymagane	Przepływ użytkownika do uruchomienia. Określ nazwę przepływu użytkownika utworzonego w dzierżawie usługi Azure AD B2C. Na przykład: b2c_1_sign_in, lub b2c_1_sign_upb2c_1_edit_profile.
client_id	Wymagane	Identyfikator aplikacji przypisany do aplikacji w Azure Portal.
response_type	Wymagane	Musi zawierać id_token logowanie openID Connect. Może również zawierać typ tokenodpowiedzi . Jeśli używasz token tego miejsca, twoja aplikacja może natychmiast otrzymać token dostępu z autoryzowanego punktu końcowego bez żądania drugiego żądania do autoryzowanego punktu końcowego. Jeśli używasz token typu odpowiedzi, parametr musi zawierać zakres wskazujący, scope który zasób ma wystawiać token.
redirect_uri	Zalecane	Identyfikator URI przekierowania aplikacji, w którym można wysyłać i odbierać odpowiedzi uwierzytelniania przez aplikację. Musi dokładnie odpowiadać jednemu z identyfikatorów URI przekierowania zarejestrowanych w portalu, z wyjątkiem tego, że musi być zakodowany pod adresem URL.
scope	Wymagane	Rozdzielona spacjami lista zakresów. W przypadku uzyskiwania tokenów uwzględnij wszystkie zakresy wymagane dla zamierzonego zasobu.
response_mode	Zalecane	Określa metodę używaną do wysyłania wynikowego tokenu z powrotem do aplikacji. W przypadku niejawnego przepływu użyj polecenia fragment. Można określić dwa inne tryby i queryform_post, ale nie działają w przepływie niejawnych.
stan	Zalecane	Wartość uwzględniona w żądaniu zwróconym w odpowiedzi tokenu. Może to być ciąg dowolnej zawartości, której chcesz użyć. Zwykle jest używana losowo wygenerowana, unikatowa wartość, aby zapobiec atakom fałszerowania żądań między witrynami. Stan jest również używany do kodowania informacji o stanie użytkownika w aplikacji przed wystąpieniem żądania uwierzytelniania. Na przykład strona lub widok użytkownika był włączony.
nonce	Wymagane	Wartość uwzględniona w żądaniu wygenerowana przez aplikację zawartą w wynikowym tokenie identyfikatora jako oświadczenie. Następnie aplikacja może zweryfikować tę wartość, aby wyeliminować ataki ponownego odtwarzania tokenu. Zazwyczaj wartość jest losowym, unikatowym ciągiem identyfikującym pochodzenie żądania.
Wierszu	Wymagane	Aby odświeżyć i pobrać tokeny w ukrytym elempcie iframe, użyj polecenia prompt=none , aby upewnić się, że element iframe nie utknie na stronie logowania i zwraca natychmiast.
login_hint	Wymagane	Aby odświeżyć i pobrać tokeny w ukrytym elempcie iframe, dołącz nazwę użytkownika w tej wskazówce, aby odróżnić wiele sesji, które użytkownik mógł mieć w danym momencie. Możesz wyodrębnić nazwę użytkownika z wcześniejszego logowania przy użyciu preferred_username oświadczenia ( profile zakres jest wymagany w celu otrzymania preferred_username oświadczenia).
domain_hint	Wymagane	Możliwe wartości to consumers i organizations. W przypadku odświeżania i pobierania tokenów w ukrytym elempcie iframe dołącz domain_hint wartość żądania. Wyodrębnij tid oświadczenie z tokenu identyfikatora wcześniejszego logowania, aby określić, która wartość ma być używana ( profile zakres jest wymagany w celu odebrania tid oświadczenia). tid Jeśli wartość oświadczenia to 9188040d-6c67-4c5b-b112-36a304b66dad, użyj polecenia domain_hint=consumers. W przeciwnym razie użyj polecenia domain_hint=organizations.

Ustawiając prompt=none parametr, to żądanie zakończy się powodzeniem lub natychmiast zakończy się niepowodzeniem i powróci do aplikacji. Pomyślna odpowiedź jest wysyłana do aplikacji za pośrednictwem identyfikatora URI przekierowania przy użyciu metody określonej w parametrze response_mode .

Pomyślna odpowiedź

Pomyślna odpowiedź przy użyciu wygląda response_mode=fragment następująco:

GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read

Parametr	Opis
access_token	Token żądany przez aplikację.
token_type	Typ tokenu będzie zawsze elementem nośnym.
stan	state Jeśli parametr jest uwzględniony w żądaniu, ta sama wartość powinna pojawić się w odpowiedzi. Aplikacja powinna sprawdzić, czy state wartości w żądaniu i odpowiedzi są identyczne.
expires_in	Jak długo token dostępu jest prawidłowy (w sekundach).
scope	Zakresy, dla których jest prawidłowy token dostępu.

Odpowiedź na błąd

Odpowiedzi na błędy można również wysłać do identyfikatora URI przekierowania, aby aplikacja mogła je odpowiednio obsłużyć. W przypadku prompt=noneprogramu oczekiwany błąd wygląda następująco:

GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently

Parametr	Opis
error	Ciąg kodu błędu, który może służyć do klasyfikowania typów błędów, które występują. Możesz również użyć ciągu, aby reagować na błędy.
error_description	Określony komunikat o błędzie, który może pomóc zidentyfikować główną przyczynę błędu uwierzytelniania.

Jeśli ten błąd zostanie wyświetlony w żądaniu elementu iframe, użytkownik musi zalogować się interaktywnie, aby pobrać nowy token.

Tokeny odświeżania

Tokeny identyfikatorów i tokeny dostępu wygasają po krótkim czasie. Aplikacja musi być przygotowana do okresowego odświeżania tych tokenów. Niejawne przepływy nie umożliwiają uzyskania tokenu odświeżania ze względów bezpieczeństwa. Aby odświeżyć dowolny typ tokenu, użyj niejawnego przepływu w ukrytym elemecie iframe HTML. W żądaniu autoryzacji dołącz prompt=none parametr . Aby otrzymać nową wartość id_token, należy użyć response_type=id_token parametru nonce i scope=openidi .

Wysyłanie żądania wylogowania

Jeśli chcesz wylogować użytkownika z aplikacji, przekieruj użytkownika do punktu końcowego wylogowania Azure AD B2C. Następnie możesz wyczyścić sesję użytkownika w aplikacji. Jeśli użytkownik nie przekierowuje użytkownika, może być w stanie ponownie uwierzytelnić aplikację bez konieczności ponownego wprowadzania poświadczeń, ponieważ mają prawidłową sesję pojedynczej Sign-On z usługą Azure AD B2C.

Możesz po prostu przekierować użytkownika do end_session_endpoint elementu wymienionego w tym samym dokumencie metadanych openID Connect opisanym w artykule Validate the ID token (Weryfikowanie tokenu identyfikatora). Na przykład:

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F

Parametr	Wymagane	Opis
{tenant}	Tak	Nazwa dzierżawy usługi Azure AD B2C.
{policy}	Tak	Przepływ użytkownika, którego chcesz użyć do wylogowania użytkownika z aplikacji. Musi to być ten sam przepływ użytkownika, w jaki aplikacja była używana do logowania użytkownika.
post_logout_redirect_uri	Nie	Adres URL, do którego użytkownik powinien zostać przekierowany po pomyślnym wylogowaniu. Jeśli nie jest uwzględniona, Azure AD B2C wyświetla użytkownikowi ogólny komunikat.
stan	Nie	state Jeśli parametr jest uwzględniony w żądaniu, ta sama wartość powinna pojawić się w odpowiedzi. Aplikacja powinna sprawdzić, czy state wartości w żądaniu i odpowiedzi są identyczne.

Uwaga

Przekierowanie użytkownika do end_session_endpoint wyczyszczenia niektórych stanu pojedynczego Sign-On użytkownika przy użyciu Azure AD B2C. Nie powoduje to jednak wylogowania użytkownika z sesji dostawcy tożsamości społecznościowych użytkownika. Jeśli użytkownik wybierze tego samego dostawcę tożsamości podczas kolejnego logowania, użytkownik zostanie ponownie uwierzytelniony bez wprowadzania poświadczeń. Jeśli użytkownik chce wylogować się z aplikacji Azure AD B2C, niekoniecznie oznacza to, że chce całkowicie wylogować się z konta na Facebooku, na przykład. Jednak w przypadku kont lokalnych sesja użytkownika zostanie prawidłowo zakończona.

Następne kroki

Zobacz przykładowy kod: logowanie się przy użyciu usługi Azure AD B2C w SPA języka JavaScript.