Logowanie do aplikacji jednostronicowej za pomocą niejawnego przepływu OAuth 2.0 w usłudze Azure Active Directory B2C

Ważne

Od 1 maja 2025 r. usługa Azure AD B2C nie będzie już dostępna do zakupu dla nowych klientów. Dowiedz się więcej w naszych często zadawanych pytaniach.

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. SPA i inne aplikacje JavaScript, które działają głównie w przeglądarce, mają kilka dodatkowych wyzwań związanych z uwierzytelnianiem:

• Charakterystyka 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ń udostępniania zasobów między źródłami (CORS).

• Przekierowania przeglądarki na całą stronę z dala od aplikacji mogą mieć wpływ na wygodę użytkownika.

Ostrzeżenie

Firma Microsoft zaleca, aby nie używać niejawnego przepływu udzielania. Zalecanym sposobem wsparcia SPA jest przepływ kodu autoryzacji OAuth 2.0 (z PKCE). Niektóre konfiguracje tego przepływu wymagają bardzo wysokiego stopnia zaufania w aplikacji i niesie ze sobą ryzyko, które nie występują w innych przepływach. Tego przepływu należy używać tylko wtedy, gdy inne bezpieczniejsze przepływy nie są opłacalne. Aby uzyskać więcej informacji, zobacz obawy dotyczące zabezpieczeń dotyczące niejawnego przepływu udzielania.

Niektóre struktury, takie jak MSAL.js 1.x, obsługują tylko niejawny przepływ udzielania. W takich przypadkach Azure Active Directory B2C (Azure AD B2C) obsługuje niejawny przepływ autoryzacji OAuth 2.0. Przepływ jest opisany w sekcji 4.2 specyfikacji OAuth 2.0. W niejawnym przepływie aplikacja odbiera tokeny bezpośrednio z punktu końcowego autoryzacji usługi Azure AD B2C bez żadnej wymiany między serwerami. Cała logika uwierzytelniania i obsługa sesji są wykonywane w całości w kliencie JavaScript za pomocą przekierowania strony lub wyskakującego okienka.

Azure AD B2C rozszerza standardowy niejawny przepływ OAuth 2.0 na więcej niż proste uwierzytelnianie i autoryzację. W usłudze Azure AD B2C wprowadzono parametr zasad. Za pomocą parametru zasad możesz użyć protokołu OAuth 2.0, aby dodać zasady do aplikacji, takie jak rejestracja, logowanie i przepływy użytkowników zarządzania profilami. W przykładowych żądaniach HTTP w tym artykule używamy {tenant}.onmicrosoft.com do ilustracji. Zastąp {tenant}nazwą najemcy, jeśli masz. Ponadto musisz mieć utworzony przepływ użytkownika.

Używamy poniższego rysunku, aby zilustrować niejawny przepływ logowania. Każdy krok jest 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 ścieżki użytkownika.

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

• {tenant} z nazwą dzierżawcy Azure AD B2C.

• Wprowadź identyfikator aplikacji, który zarejestrowałeś w twojej dzierżawie.

• {policy} z nazwą polityki, którą utworzyłeś w swojej dzierżawie, na przykład b2c_1_sign_in.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&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 są wyjaśnione w poniższej tabeli.

Parametr	Wymagane	Opis
{najemca}	Tak	Nazwa dzierżawy usługi Azure AD B2C
{polityka}	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.
identyfikator_klienta	Tak	Identyfikator aplikacji przypisany przez portal Azure do twojej aplikacji.
typ_odpowiedzi	Tak	Koniecznie należy uwzględnić id_token przy logowaniu się za pomocą OpenID Connect. Może również zawierać typ odpowiedzi token. Jeśli używasz tokenprogramu , aplikacja może natychmiast otrzymać token dostępu z punktu końcowego autoryzacji bez wysyłania drugiego żądania do punktu końcowego autoryzacji. Jeśli używasz token typu odpowiedzi, scope parametr musi zawierać zakres wskazujący zasób, dla którego ma zostać wystawiony token.
adres_przekierowania	Nie.	Identyfikator URI przekierowania aplikacji, w którym można wysyłać i odbierać odpowiedzi uwierzytelniania przez aplikację. Musi on być dokładnie zgodny z jednym z identyfikatorów URI przekierowania dodanych do zarejestrowanej aplikacji w portalu, z tą różnicą, że musi być zakodowany w adresie URL.
Tryb_odpowiedzi	Nie.	Określa metodę, która ma być używana do wysyłania wynikowego tokenu z powrotem do aplikacji. W przypadku przepływów niejawnych użyj fragment.
zakres	Tak	Rozdzielona spacjami lista zakresów. Pojedyncza wartość zakresu informuje Microsoft Entra ID o obu żądanych uprawnieniach. Zakres openid wskazuje uprawnienie do logowania użytkownika i uzyskiwania danych o użytkowniku w postaci tokenów identyfikatorów. Zakres offline_access jest opcjonalny w przypadku aplikacji internetowych. Oznacza to, że aplikacja potrzebuje tokenu odświeżania w celu uzyskania długotrwałego dostępu do zasobów.
stan / państwo	Nie.	Wartość zawarta w żądaniu, która jest również zwracana w odpowiedzi tokenu. Może to być ciąg dowolnej treści, której chcesz użyć. Zazwyczaj używana jest losowo wygenerowana, unikalna wartość, aby zapobiec atakom typu cross-site request forgery. 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órej znajdował się użytkownik, lub przepływu użytkownika, który był wykonywany.
nonce	Tak	Wartość zawarta w żądaniu (wygenerowana przez aplikację), która jest uwzględniona 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, którego można użyć do zidentyfikowania pochodzenia żądania.
zachęta	Nie.	Typ interakcji z użytkownikiem, który jest wymagany. Obecnie jedyną prawidłową wartością jest login. Ten parametr wymusza na użytkowniku wprowadzenie poświadczeń przy tym żądaniu. Pojedyncze Sign-On nie obowiązuje.

Jest to interaktywna część procesu. Użytkownik jest proszony o ukończenie przepływu pracy zasad. Użytkownik może być zmuszony do wprowadzenia swojej nazwy użytkownika i hasła, zalogowania się przy użyciu tożsamości społecznościowej, zarejestrowania się w celu uzyskania konta lokalnego lub dowolnej innej liczby kroków. Akcje użytkownika zależą od sposobu definiowania przepływu użytkownika.

Gdy użytkownik ukończy przepływ użytkownika, Azure AD B2C zwraca odpowiedź do twojej 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.

Odpowiedź pomyślna

Pomyślna odpowiedź, która używa response_mode=fragment i response_type=id_token+token wygląda podobnie do poniższej, z podziałami wierszy w celu zapewnienia czytelności:

GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier

Parametr	Opis
token dostępu	Token dostępu, którego aplikacja zażądała od usługi Azure AD B2C.
typ tokena	Wartość typu tokenu. Jedynym typem obsługiwanym przez Azure AD B2C jest Bearer.
wygasa_za	Czas ważności tokenu dostępu (w sekundach).
zakres	Zakresy, dla których token jest prawidłowy. Można również użyć zakresów do buforowania tokenów do późniejszego użycia.
token identyfikacyjny	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ę tokenów usługi Azure AD B2C.
stan / państwo	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

Można także wysyłać odpowiedzi na błędy do URI przekierowania, aby aplikacja mogła je obsłużyć w odpowiedni sposób.

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
błąd	Kod używany do klasyfikowania typów występujących błędów.
opis błędu	Określony komunikat o błędzie, który może pomóc zidentyfikować główną przyczynę błędu uwierzytelniania.
stan / państwo	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

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

Dostępnych jest wiele bibliotek typu open source do sprawdzania poprawności JWT, w zależności od preferowanego języka. Rozważ zapoznanie się z dostępnymi bibliotekami typu open source, zamiast implementowania własnej logiki walidacji. Możesz skorzystać z informacji zawartych w tym artykule, aby dowiedzieć się, jak prawidłowo korzystać z tych bibliotek.

Usługa Azure AD B2C ma punkt końcowy metadanych OpenID Connect. Aplikacja może używać punktu końcowego do pobierania informacji o usłudze 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żawcy znajduje się pod adresem fabrikamb2c.onmicrosoft.com.

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 konfiguracyjnego jest jwks_uri. Wartość dla tego samego przepływu użytkownika będzie następująca:

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 skąd pobrać metadane), możesz użyć dowolnej z następujących opcji:

• Nazwa przepływu użytkownika jest zawarta w acr żądaniu w id_token. Aby uzyskać informacje na temat analizowania oświadczeń na podstawie tokenu identyfikatora, zobacz dokumentację tokenu Azure AD B2C.

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

Po pobraniu 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) w celu zweryfikowania podpisu tokenu identyfikatora. W dowolnym momencie może być wiele kluczy wymienionych w tym punkcie końcowym, z których każdy jest identyfikowany przez kid. Nagłówek id_token zawiera również kid oświadczenie. Wskazuje, który z tych kluczy został użyty do podpisania tokenu identyfikatora. Aby uzyskać więcej informacji, w tym informacje na temat weryfikowania tokenów, zobacz dokumentację tokenów Azure AD B2C.

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

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

• Sprawdź poprawność aud oświadczenia, aby upewnić się, że token identyfikatora został wystawiony dla Twojej aplikacji. Jego wartość powinna być identyfikatorem aplikacji.

• Sprawdź poprawność iatexp i oświadczenia, aby upewnić się, że token identyfikatora nie wygasł.

Kilka dodatkowych walidacji, które należy wykonać, jest szczegółowo opisanych w specyfikacji OpenID Connect Core Spec. Możesz również zweryfikować dodatkowe oświadczenia, w zależności od scenariusza. Oto niektóre typowe walidacje:

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

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

• Upewnienie się, że wystąpiła określona 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ę tokenu usługi Azure AD B2C.

Po zweryfikowaniu tokenu identyfikatora możesz rozpocząć sesję z użytkownikiem. W aplikacji użyj twierdzeń w tokenie identyfikatora, aby uzyskać informacje o użytkowniku. Te informacje mogą być używane do wyświetlania, rejestrowania, autoryzacji i tak dalej.

Uzyskiwanie tokenów dostępu

Jeśli jedyną rzeczą, którą muszą zrobić Twoje aplikacje internetowe, jest wykonywanie przepływów użytkownika, możesz pominąć kilka następnych sekcji. Informacje w poniższych sekcjach mają zastosowanie tylko do aplikacji internetowych, które muszą wykonywać uwierzytelnione wywołania internetowego interfejsu API chronionego przez samą usługę Azure AD B2C.

Teraz, po zalogowaniu użytkownika do SPA, możesz uzyskać tokeny dostępu do wywoływania internetowych interfejsów API, które są zabezpieczone przez identyfikator Microsoft Entra. Nawet jeśli token został już otrzymany 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 zalogowania się.

W typowym przepływie aplikacji internetowej należy wysłać żądanie do /token punktu końcowego. Jednak punkt końcowy nie obsługuje żądań CORS, więc 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 elemencie iframe HTML, aby uzyskać nowe tokeny dla innych internetowych interfejsów API. Oto przykład z podziałami wierszy w celu zwiększenia czytelności:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&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
{najemca}	Wymagane	Nazwa dzierżawy usługi Azure AD B2C
{polityka}	Wymagane	Proces użytkownika, który ma zostać uruchomiony. 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.
identyfikator_klienta	Wymagane	Identyfikator aplikacji przypisany do aplikacji w witrynie Azure Portal.
typ_odpowiedzi	Wymagane	Musi zawierać id_token w celu logowania za pomocą OpenID Connect. Może również zawierać typ odpowiedzi token. Jeśli używasz token tego miejsca, aplikacja może natychmiast otrzymać token dostępu z punktu końcowego autoryzacji bez wysyłania drugiego żądania do punktu końcowego autoryzacji. Jeśli używasz token typu odpowiedzi, scope parametr musi zawierać zakres wskazujący zasób, dla którego ma zostać wystawiony token.
adres_przekierowania	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 tą różnicą, że musi być zakodowana pod adresem URL.
zakres	Wymagane	Rozdzielona spacjami lista zakresów. Aby uzyskać tokeny, uwzględnij wszystkie zakresy, które są wymagane dla zamierzonego zasobu.
Tryb_odpowiedzi	Zalecane	Określa metodę, która jest używana do wysyłania wynikowego tokenu z powrotem do aplikacji. W przypadku przepływu niejawnego użyj fragment. Można określić query dwa inne tryby i form_post, ale nie działają w niejawnym przepływie.
stan / państwo	Zalecane	Wartość uwzględniona w żądaniu jest zwracana w odpowiedzi na token. Może to być ciąg dowolnej treści, której chcesz użyć. Zazwyczaj używana jest losowo wygenerowana, unikalna wartość, aby zapobiec atakom typu cross-site request forgery. Stan jest również używany do kodowania informacji o stanie użytkownika w aplikacji przed wystąpieniem żądania uwierzytelnienia. Na przykład strona lub widok, na którym znajdował się użytkownik.
nonce	Wymagane	Wartość zawarta w żądaniu wygenerowana przez aplikację, która jest uwzględniona 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, który identyfikuje pochodzenie żądania.
zachęta	Wymagane	Aby odświeżyć i pobrać tokeny w ukrytym iframie, użyj prompt=none, aby upewnić się, że iframe nie utknie na stronie logowania i natychmiast się zwróci.
podpowiedź do logowania	Wymagane	Aby odświeżyć i pobrać tokeny w ukrytym elemencie iframe, dołącz nazwę użytkownika do tej wskazówki, aby rozróżnić wiele sesji, które użytkownik może mieć w danym momencie. Możesz wyodrębnić nazwę użytkownika z wcześniejszego logowania przy użyciu oświadczenia preferred_username (zakres profile jest wymagany do otrzymania oświadczenia preferred_username).
wskazówka dotycząca domeny	Wymagane	Możliwe wartości to consumers i organizations. Aby odświeżyć i pobrać tokeny w ukrytym elemencie iframe, uwzględnij wartość domain_hint w żądaniu. Wyodrębnij tid roszczenie z tokenu identyfikatora z wcześniejszego logowania, aby określić, którą wartość należy używać (zakres profile jest wymagany do otrzymania roszczenia tid). tid Jeśli wartość oświadczenia wynosi 9188040d-6c67-4c5b-b112-36a304b66dad, użyj domain_hint=consumers. W przeciwnym razie użyj domain_hint=organizations.

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

Odpowiedź pomyślna

Pomyślna odpowiedź przy użyciu response_mode=fragment wygląda podobnie do tego przykładu:

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
token dostępu	Token zażądany przez aplikację.
typ tokena	Typem tokenu będzie zawsze Bearer.
stan / państwo	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.
wygasa_za	Jak długo token dostępu jest prawidłowy (w sekundach).
zakres	Zakresy, dla których token dostępu jest prawidłowy.

Odpowiedź na błąd

Odpowiedzi o błędach mogą być wysyłane również do identyfikatora URI przekierowania, aby aplikacja mogła je odpowiednio obsłużyć. W przypadku prompt=none, oczekiwany błąd wygląda tak jak ten przykład.

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

Parametr	Opis
błąd	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.
opis błędu	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.

Odświeżanie tokenów

Zarówno tokeny identyfikatorów, jak 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 zezwalają na uzyskanie tokenu odświeżania ze względów bezpieczeństwa. Aby odświeżyć dowolny typ tokenu, użyj ukrytego przepływu w niewidocznym elemencie iframe HTML. W żądaniu autoryzacji uwzględnij parametr.prompt=none Aby otrzymać nową wartość id_token, pamiętaj o użyciu response_type=id_token, scope=openid oraz parametru nonce.

Wysyłanie żądania wylogowania

Jeśli chcesz wylogować użytkownika z aplikacji, przekieruj go do punktu końcowego wylogowania Azure AD B2C. Następnie możesz wyczyścić sesję użytkownika w aplikacji. Jeśli użytkownik nie zostanie przekierowany, mogą ponownie uwierzytelnić się w aplikacji bez konieczności ponownego wprowadzania poświadczeń, ponieważ mają prawidłową sesję typu Single Sign-On z Azure AD B2C.

Możesz po prostu przekierować użytkownika do end_session_endpoint, który jest wymieniony w tym samym dokumencie metadanych OpenID Connect opisanym w temacie Weryfikowanie tokenu identyfikatora. 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
{najemca}	Tak	Nazwa Twojego dzierżawcy Azure AD B2C.
{polityka}	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, który został użyty przez aplikację do zalogowania użytkownika.
adnotacja_przekierowania_po_wylogowaniu_uri	Nie.	Adres URL, do którego użytkownik powinien zostać przekierowany po pomyślnym wylogowaniu. Jeśli nie zostanie ona dołączona, usługa Azure AD B2C wyświetli użytkownikowi ogólny komunikat.
stan / państwo	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 / Notatka

Przekierowanie użytkownika do end_session_endpoint powoduje wyczyszczenie części stanu pojedynczego Sign-On użytkownika w Azure AD B2C. Nie powoduje to jednak wylogowania użytkownika z sesji dostawcy tożsamości społecznościowej użytkownika. Jeśli użytkownik wybierze tego samego dostawcę tożsamości podczas kolejnego logowania, zostanie ponownie uwierzytelniony bez wprowadzania swoich poświadczeń. Jeśli użytkownik chce wylogować się z aplikacji Azure AD B2C, nie musi to oznaczać, że chce całkowicie wylogować się ze swojego konta w serwisie Facebook, na przykład. Jednak w przypadku kont lokalnych sesja użytkownika zostanie zakończona poprawnie.

Dalsze kroki

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