Udostępnij za pośrednictwem

Przepływ kodu autoryzacji 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.

Możesz użyć udzielania kodu autoryzacji OAuth 2.0 w aplikacjach zainstalowanych na urządzeniu, aby uzyskać dostęp do chronionych zasobów, takich jak internetowe interfejsy API. Korzystając z implementacji protokołu OAuth 2.0 usługi Azure Active Directory B2C (Azure AD B2C), można dodawać zadania rejestracji, logowania i innych zadań zarządzania tożsamościami do jednostronicowych, mobilnych i klasycznych aplikacji. W tym artykule opisano sposób wysyłania i odbierania komunikatów HTTP bez używania żadnych bibliotek typu open source. Ten artykuł jest niezależny od języka. Jeśli to możliwe, zalecamy użycie obsługiwanych bibliotek uwierzytelniania firmy Microsoft (MSAL). Przyjrzyj się przykładowym aplikacjom korzystającym z biblioteki MSAL.

Przepływ kodu autoryzacji OAuth 2.0 został opisany w sekcji 4.1 specyfikacji OAuth 2.0. Można go używać do uwierzytelniania i autoryzacji w większości typów aplikacji, w tym aplikacji internetowych, aplikacji jednostronicowych i natywnie zainstalowanych aplikacji. Możesz użyć przepływu kodu autoryzacji OAuth 2.0, aby bezpiecznie uzyskać tokeny dostępu i odświeżyć tokeny dla aplikacji, które mogą służyć do uzyskiwania dostępu do zasobów zabezpieczonych przez serwer autoryzacji. Token odświeżania pozwala klientowi na uzyskanie nowych tokenów dostępu i odświeżania, gdy token dostępu wygasa, zazwyczaj po jednej godzinie.

Ten artykuł koncentruje się na przepływie kodu autoryzacji OAuth 2.0 klientów publicznych . Klient publiczny to każda aplikacja kliencka, która nie może być zaufana, aby bezpiecznie zachować integralność tajnego hasła. Obejmuje to aplikacje jednostronicowe, aplikacje mobilne, aplikacje klasyczne i zasadniczo dowolną aplikację, która nie działa na serwerze.

Uwaga

Aby dodać zarządzanie tożsamościami do aplikacji internetowej przy użyciu usługi Azure AD B2C, użyj protokołu OpenID Connect zamiast protokołu OAuth 2.0.

Usługa Azure AD B2C rozszerza standardowe przepływy OAuth 2.0, aby wykonywać więcej niż proste uwierzytelnianie i autoryzację. Wprowadza przepływ użytkownika. Za pomocą przepływów użytkowników możesz użyć protokołu OAuth 2.0, aby dodać doświadczenia użytkownika do aplikacji, takie jak rejestracja, logowanie się i zarządzanie profilami. Dostawcy tożsamości korzystający z protokołu OAuth 2.0 to Amazon, Microsoft Entra ID, Facebook, GitHub, Google i LinkedIn.

Aby wypróbować żądania HTTP w tym artykule:

  1. Zastąp {tenant} nazwą dzierżawy usługi Azure AD B2C.
  2. Zastąp 00001111-aaaa-2222-bbbb-3333cccc4444 identyfikatorem aplikacji, którą wcześniej zarejestrowałeś/zarejestrowałaś w dzierżawie Azure AD B2C.
  3. Zastąp {policy} nazwą zasady, które utworzyłeś w swojej dzierżawie, na przykład b2c_1_sign_in.

Konfiguracja URI przekierowania jest wymagana dla aplikacji jednostronicowych

Przepływ kodu autoryzacji dla aplikacji jednostronicowych wymaga dodatkowej konfiguracji. Postępuj zgodnie z instrukcjami dotyczącymi tworzenia aplikacji jednostronicowej aby poprawnie zaznaczyć identyfikator URI przekierowania jako dozwolony dla mechanizmu CORS. Aby zaktualizować istniejący identyfikator URI przekierowania w celu włączenia mechanizmu CORS, możesz kliknąć monit migracji w sekcji "Sieć Web" na karcie Rejestracja aplikacjiUwierzytelnianie. Alternatywnie możesz otworzyć Edytor manifestu rejestracji aplikacji i ustawić pole type dla identyfikatora URI przekierowania na wartość spa w sekcji replyUrlsWithType.

spa Typ przekierowania jest do tyłu zgodny z niejawnym przepływem. Aplikacje, które obecnie korzystają z niejawnego przepływu do pobierania tokenów, mogą bez problemu przejść do typu przekierowania URI spa i nadal używać niejawnego przepływu.

1. Pobieranie kodu autoryzacji

Przepływ kodu autoryzacji rozpoczyna się od klienta kierującego użytkownika do punktu końcowego /authorize . Jest to interaktywna część przepływu, w której użytkownik podejmuje działania. W tym żądaniu klient wskazuje w parametrze scope uprawnienia, które musi uzyskać od użytkownika. W poniższych przykładach (z podziałami wierszy na potrzeby czytelności) pokazano, jak uzyskać kod autoryzacji. Jeśli testujesz to żądanie HTTP GET, użyj przeglądarki.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=00001111-aaaa-2222-bbbb-3333cccc4444%20offline_access%20https://{tenant-name}/{app-id-uri}/{scope}
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
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 Typ odpowiedzi, który musi zawierać code dla przepływu kodu autoryzacji. Możesz otrzymać token identyfikacyjny, jeśli uwzględnisz go w typie odpowiedzi, takim jak code+id_token. W takim przypadku zakres musi obejmować openid.
adres_przekierowania Wymagane Identyfikator URI przekierowania Twojej aplikacji, do którego odpowiedzi uwierzytelniania są wysyłane i odbierane przez Twoją aplikację. Musi dokładnie odpowiadać jednemu z identyfikatorów URI przekierowania zarejestrowanych w portalu, z tą różnicą, że musi być zakodowany jako URL.
zakres Wymagane Rozdzielona spacjami lista zakresów. 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 dla aplikacji internetowych. Wskazuje ona, że aplikacja potrzebuje tokenu odświeżania w celu uzyskania rozszerzonego dostępu do zasobów. Identyfikator klienta wskazuje, że wystawiony token jest przeznaczony do użycia przez zarejestrowanego klienta usługi Azure AD B2C. Element https://{tenant-name}/{app-id-uri}/{scope} wskazuje uprawnienie do chronionych zasobów, takich jak internetowy interfejs API. Aby uzyskać więcej informacji, zobacz Żądanie tokenu dostępu.
Tryb_odpowiedzi Zalecane Metoda używana do wysyłania wynikowego kodu autoryzacji z powrotem do aplikacji. Może to być query, form_postlub fragment.
stan / państwo Zalecane Wartość uwzględniona w żądaniu, która może być ciągiem dowolnej zawartości, której chcesz użyć. Zazwyczaj jest używana losowo wygenerowana unikatowa wartość, aby zapobiec atakom fałszerzowanym żą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 strona, na której znajdował się użytkownik, lub przepływ użytkownika, który był realizowany.
zachęta Opcjonalnie Wymagany typ interakcji użytkownika. Obecnie jedyną prawidłową wartością jest login, która wymusza na użytkowniku wprowadzanie poświadczeń na tym żądaniu. Logowanie jednokrotne nie zostanie zastosowane.
wyzwanie kodowania zalecane/wymagane Służy do zabezpieczania udzielania kodu autoryzacji za pośrednictwem klucza dowodowego na potrzeby wymiany kodu (PKCE). Wymagane, jeśli code_challenge_method jest uwzględnione. Musisz dodać logikę w aplikacji, aby wygenerować element code_verifier i code_challenge. code_challenge to zakodowany w formacie Base64 URL skrót SHA256 code_verifier. Przechowujesz code_verifier w aplikacji do późniejszego użycia i wysyłasz code_challenge wraz z żądaniem autoryzacji. Aby uzyskać więcej informacji, zobacz PKCE RFC. Jest to teraz zalecane dla wszystkich typów aplikacji — aplikacji natywnych, SPA i poufnych klientów, takich jak aplikacje internetowe.
code_challenge_method zalecane/wymagane Metoda używana do kodowania code_verifier dla parametru code_challenge. POWINNA to być S256, ale specyfikacja zezwala na użycie plain jeśli z jakiegoś powodu klient nie może obsługiwać algorytmu SHA256.

Jeśli wykluczysz element code_challenge_method, ale nadal dołączysz element code_challenge, wtedy zakłada się, że code_challenge jest zwykłym tekstem. Platforma tożsamości firmy Microsoft obsługuje zarówno plain, jak i S256. Aby uzyskać więcej informacji, zobacz PKCE RFC. Jest to wymagane w przypadku aplikacji jednostronicowych przy użyciu przepływu kodu autoryzacji.
podpowiedź do logowania Nie. Może służyć do wstępnego wypełniania pola nazwy logowania na stronie logowania. Aby uzyskać więcej informacji, zobacz Wstępne wypełnianie nazwy logowania.
wskazówka dotycząca domeny Nie. Zawiera wskazówkę dotyczącą dostawcy tożsamości społecznościowych usługi Azure AD B2C, który powinien być używany do logowania. Jeśli zostanie uwzględniona prawidłowa wartość, użytkownik przejdzie bezpośrednio do strony logowania dostawcy tożsamości. Aby uzyskać więcej informacji, zobacz Przekierowanie logowania do dostawcy społecznościowego.
Parametry niestandardowe Nie. Parametry niestandardowe, których można używać z zasadami niestandardowymi. Na przykład dynamiczne identyfikatory URI zawartości strony niestandardowej lub metody rozpoznawania oświadczeń klucz-wartość.

Na tym etapie użytkownik jest proszony o ukończenie procesu przepływu użytkownika. Może to obejmować wprowadzenie nazwy użytkownika i hasła, zalogowanie się przy użyciu tożsamości społecznościowej, zarejestrowanie się w katalogu lub dowolną inną liczbę kroków. Akcje użytkownika zależą od sposobu definiowania przepływu użytkownika.

Po zakończeniu przepływu użytkownika Microsoft Entra ID zwraca odpowiedź do Twojej aplikacji, wykorzystując wartość, którą użyłeś dla elementu 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ź, która używa response_mode=query , wygląda następująco:

GET urn:ietf:wg:oauth:2.0:oob?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...        // the authorization_code, truncated
&state=arbitrary_data_you_can_receive_in_the_response                // the value provided in the request
Parametr Opis
kod Kod autoryzacji żądany przez aplikację. Aplikacja może użyć kodu autoryzacji, aby zażądać tokenu dostępu dla zasobu docelowego. Kody autoryzacji są krótkotrwałe. Zazwyczaj wygasają po około 10 minutach.
stan / państwo Zobacz pełny opis w tabeli w poprzedniej sekcji. 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.

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 urn:ietf:wg:oauth:2.0:oob?
error=access_denied
&error_description=The+user+has+cancelled+entering+self-asserted+information
&state=arbitrary_data_you_can_receive_in_the_response
Parametr Opis
błąd Ciąg kodu błędu, którego można 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.
stan / państwo Zobacz pełny opis w poprzedniej tabeli. 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.

2. Uzyskiwanie tokenu dostępu

Po uzyskaniu kodu autoryzacji możesz zrealizować code na token dla przeznaczonego zasobu, wysyłając żądanie POST do punktu końcowego /token. W usłudze Azure AD B2C możesz żądać tokenów dostępu dla innych interfejsów API w zwykły sposób, określając ich zakresy w żądaniu.

Możesz również zażądać tokenu dostępu dla własnego internetowego interfejsu API zaplecza aplikacji zgodnie z konwencją użycia identyfikatora klienta aplikacji jako żądanego zakresu (co spowoduje token dostępu z tym identyfikatorem klienta jako "odbiorcy"):

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
Parametr Wymagane? Opis
{najemca} Wymagane Nazwa dzierżawy usługi Azure AD B2C
{polityka} Wymagane Przepływ użytkownika, który został użyty do uzyskania kodu autoryzacji. Nie można użyć innego przepływu użytkownika w tym żądaniu.
identyfikator_klienta Wymagane Identyfikator aplikacji przypisany do aplikacji w witrynie Azure Portal.
tajemnica klienta Tak, w usłudze Web Apps Tajny klucz aplikacji, który został wygenerowany w portalu Azure. Tajne dane klienta są używane w tym przepływie w scenariuszach aplikacji webowych, w których klient może bezpiecznie przechowywać swoje tajne dane. W scenariuszach aplikacji natywnej (klienta publicznego) tajne klucze klientów nie mogą być bezpiecznie przechowywane, dlatego nie są używane w tym wywołaniu. Jeśli używasz tajemnicy klienta, okresowo zmieniaj ją.
typ_grantu Wymagane Typ udzielenia. W przypadku przepływu kodu autoryzacji typ udzielenia musi mieć wartość authorization_code.
zakres Zalecane Rozdzielona spacjami lista zakresów. Jedna wartość zakresu wskazuje usługie Azure AD B2C wszystkie żądane uprawnienia. Użycie identyfikatora klienta jako zakresu wskazuje, że aplikacja potrzebuje tokenu dostępu, który może być używany dla własnej usługi lub internetowego interfejsu API reprezentowanego przez ten sam identyfikator klienta. Zakres offline_access wskazuje, że aplikacja potrzebuje tokenu odświeżania na potrzeby długotrwałego dostępu do zasobów. Możesz również użyć openid zakresu, aby zażądać tokenu identyfikatora z usługi Azure AD B2C.
kod Wymagane Kod autoryzacji uzyskany z punktu końcowego /authorize .
adres_przekierowania Wymagane Identyfikator URI przekierowania aplikacji, w której odebrałeś kod autoryzacji.
weryfikator_kodu zalecane To samo code_verifier używane do uzyskania kodu autoryzacji. Wymagane, jeśli klucz PKCE został użyty w żądaniu udzielenia kodu autoryzacji. Aby uzyskać więcej informacji, zobacz PKCE RFC.

Jeśli testujesz to żądanie HTTP POST, możesz użyć dowolnego klienta HTTP, takiego jak program Microsoft PowerShell.

Pomyślna odpowiedź tokenu wygląda następująco:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parametr Opis
nie wcześniej niż Czas, w którym token jest uznawany za prawidłowy, w czasie epoki.
typ tokena Wartość typu tokenu. Jedynym typem, który obsługuje identyfikator Entra firmy Microsoft, jest bearer.
token dostępu Podpisany token internetowy JSON (JWT), którego zażądano.
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.
wygasa_za Czas ważności tokenu (w sekundach).
token odświeżania Token odświeżania OAuth 2.0. Aplikacja może użyć tego tokenu, aby uzyskać dodatkowe tokeny po wygaśnięciu bieżącego tokenu. Tokeny odświeżania są długoterminowe. Można ich użyć, aby zachować dostęp do zasobów przez dłuższy czas. Aby uzyskać więcej informacji, zobacz dokumentację tokenu usługi Azure AD B2C.

Odpowiedzi na błędy wyglądają następująco:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Parametr Opis
błąd Ciąg kodu błędu, którego można 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.

3. Użyj tokenu

Po pomyślnym uzyskaniu tokenu dostępu możesz użyć go w żądaniach do interfejsów API serwera, dołączając token do nagłówka Authorization.

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

4. Odśwież token

Tokeny dostępu i tokeny identyfikatorów są krótkotrwałe. Po wygaśnięciu należy je odświeżyć, aby nadal uzyskiwać dostęp do zasobów. Podczas odświeżania tokenu dostępu usługa Azure AD B2C zwraca nowy token. Odświeżony token dostępu będzie miał zaktualizowane wartości roszczeń: nbf (nie wcześniej), iat (wystawiony) i exp (wygaśnięcie). Wszystkie inne wartości roszczeń są identyczne z oryginalnie wystawionego tokenu dostępu.

Aby odświeżyć token, prześlij kolejne żądanie POST do punktu końcowego /token . Tym razem podaj wartość refresh_token zamiast elementu code:

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parametr Wymagane? Opis
{najemca} Wymagane Nazwa dzierżawy usługi Azure AD B2C
{polityka} Wymagane Przepływ użytkownika, który został użyty do uzyskania oryginalnego tokenu odświeżania. Nie można użyć innego przepływu użytkownika w tym żądaniu.
identyfikator_klienta Wymagane Identyfikator aplikacji przypisany do aplikacji w witrynie Azure Portal.
tajemnica klienta Tak, w usłudze Web Apps Tajny klucz aplikacji, który został wygenerowany w portalu Azure. Tajne dane klienta są używane w tym przepływie w scenariuszach aplikacji webowych, w których klient może bezpiecznie przechowywać swoje tajne dane. W scenariuszach aplikacji natywnej (klienta publicznego) tajne klucze klientów nie mogą być bezpiecznie przechowywane, dlatego nie są używane w tym wywołaniu. Jeśli używasz tajnego klucza klienta, zmieniaj go regularnie.
typ_grantu Wymagane Typ udzielenia. W tej części przepływu kodu autoryzacji typ udzielenia musi mieć wartość refresh_token.
zakres Zalecane Rozdzielona spacjami lista zakresów. Pojedyncza wartość zakresu informuje Microsoft Entra ID o obu żądanych uprawnieniach. Użycie identyfikatora klienta jako zakresu wskazuje, że aplikacja potrzebuje tokenu dostępu, który może być używany dla własnej usługi lub internetowego interfejsu API reprezentowanego przez ten sam identyfikator klienta. Zakres offline_access wskazuje, że aplikacja potrzebuje tokenu odświeżania na potrzeby długotrwałego dostępu do zasobów. Możesz również użyć openid zakresu, aby zażądać tokenu identyfikatora z usługi Azure AD B2C.
adres_przekierowania Opcjonalnie Identyfikator URI przekierowania aplikacji, w której odebrałeś kod autoryzacji.
token odświeżania Wymagane Oryginalny token odświeżania uzyskany w drugim etapie przepływu.

Pomyślna odpowiedź tokenu wygląda następująco:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parametr Opis
nie wcześniej niż Czas, w którym token jest uznawany za prawidłowy, w czasie epoki.
typ tokena Wartość typu tokenu. Jedynym typem, który obsługuje identyfikator Entra firmy Microsoft, jest bearer.
token dostępu Podpisany token JWT, o który proszono.
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.
wygasa_za Czas ważności tokenu (w sekundach).
token odświeżania Token odświeżania OAuth 2.0. Aplikacja może użyć tego tokenu, aby uzyskać dodatkowe tokeny po wygaśnięciu bieżącego tokenu. Tokeny odświeżania są długotrwałe i mogą być używane do przechowywania dostępu do zasobów przez dłuższy czas. Aby uzyskać więcej informacji, zobacz dokumentację tokenu usługi Azure AD B2C.

Odpowiedzi na błędy wyglądają następująco:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Parametr Opis
błąd Ciąg kodu błędu, którego można 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.

Korzystanie z własnego katalogu usługi Azure AD B2C

Aby samodzielnie wypróbować te żądania, wykonaj następujące kroki. Zastąp przykładowe wartości użyte w tym artykule własnymi wartościami.

  1. Utwórz katalog usługi Azure AD B2C. Użyj nazwy katalogu w żądaniach.
  2. Utwórz aplikację, aby uzyskać identyfikator aplikacji i identyfikator URI przekierowania. Uwzględnij klienta natywnego w aplikacji.
  3. Utwórz przepływy użytkownika, aby uzyskać nazwy przepływów użytkownika.