Logowanie jednostronicowe aplikacji przy użyciu 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

Microsoft zaleca nie używać niejawnego przepływu autoryzacji. 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, zasięgnij obaw związanych z zabezpieczeniami przy niejawnej metodzie udzielania dostępu.

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 udzielania autoryzacji OAuth 2.0. Przepływ jest 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 żadnej wymiany serwer-serwer. 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 przepływ niejawny OAuth 2.0 na coś więcej niż proste uwierzytelnianie i autoryzację. Azure AD B2C wprowadza parametr policy. 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ą instancji dzierżawy usługi 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, gdzie aplikacja może wysyłać i odbierać odpowiedzi uwierzytelniania. 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 wskazuje Microsoft Entra ID obu żądanych uprawnień. 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	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.
identyfikator jednorazowy	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.
monit	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.

Po zakończeniu przepływu użytkownika usługa Azure AD B2C zwraca odpowiedź na aplikację 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 żądany przez aplikację z usługi Azure AD B2C.
typ tokena	Wartość typu tokenu. Jedynym typem, który obsługuje usługa 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 ID i ich zawartości, zobacz odniesienie do tokenów usługi Azure AD 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

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	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 JSON Web Tokens (JWTs) i kryptografii klucza publicznego w celu podpisywania tokenów i sprawdzania, czy są 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.

Azure AD B2C ma punkt końcowy do 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. Dla każdego przepływu użytkownika w dzierżawie Azure AD B2C istnieje dokument metadanych JSON. 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ń z tokenu ID, zobacz w dokumentacji tokenów 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 na temat walidacji tokenów, zobacz referencję 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 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 ID tokenie, zobacz dokumentację tokenu 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 przedstawione w poniższych sekcjach dotyczą tylko aplikacji internetowych, które muszą wykonywać uwierzytelnione wywołania do 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 Microsoft Entra ID. 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 portalu Azure.
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, gdzie aplikacja może wysyłać i odbierać odpowiedzi uwierzytelniania. Musi dokładnie odpowiadać jednemu z identyfikatorów URI przekierowania zarejestrowanych w portalu, z tą różnicą, że musi być zakodowana w formacie 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	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.
identyfikator jednorazowy	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.
monit	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	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 w żądaniu iframe wystąpi ten błąd, użytkownik musi ponownie 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 użytkownika do punktu końcowego wylogowania usługi AD B2C Azure. Następnie możesz wyczyścić sesję użytkownika w aplikacji. Jeśli nie przekierujesz użytkownika, może on ponownie uwierzytelnić się w aplikacji bez konieczności ponownego wprowadzania poświadczeń, ponieważ ma prawidłową sesję jednokrotnego logowania z usługą 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 Twojej dzierżawy usługi 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 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 / Notatka

Przekierowanie użytkownika do end_session_endpoint czyści niektóre informacje dotyczące logowania jednokrotnego użytkownika z usługą 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 usługi Azure AD B2C, niekoniecznie oznacza to, że chce całkowicie wylogować się ze swojego konta na Facebooku, na przykład. Jednak w przypadku kont lokalnych sesja użytkownika zostanie zakończona poprawnie.

Dalsze kroki

Zobacz przykładowy kod: Sign-in with Azure AD B2C in a JavaScript SPA.