Konfigurowanie przepływu poświadczeń hasła właściciela zasobu w usłudze Azure Active Directory B2C

2025-05-06

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.

Przed rozpoczęciem użyj selektora Wybierz typ zasad w górnej części tej strony, aby wybrać typ konfigurowanych zasad. Usługa Azure Active Directory B2C oferuje dwie metody definiowania sposobu interakcji użytkowników z aplikacjami: za pomocą wstępnie zdefiniowanych przepływów użytkowników lub w pełni konfigurowalnych zasad niestandardowych. Kroki wymagane w tym artykule są różne dla każdej metody.

W usłudze Azure Active Directory B2C (Azure AD B2C) przepływ poświadczeń hasła właściciela zasobu (ROPC) to standardowy przepływ uwierzytelniania OAuth. W tym przepływie aplikacja, znana również jako strona ufająca, wymienia prawidłowe poświadczenia na tokeny. Poświadczenia obejmują identyfikator użytkownika i hasło. Zwrócone tokeny to token identyfikatora, token dostępu i token odświeżania.

Ostrzeżenie

Zalecamy, aby nie używać przepływu ROPC. W większości scenariuszy dostępne są bezpieczniejsze alternatywy i zalecane. Ten przepływ wymaga bardzo wysokiego poziomu zaufania w aplikacji i niesie ze sobą ryzyko, które nie są obecne w innych przepływach. Tego przepływu należy używać tylko wtedy, gdy inne bezpieczniejsze przepływy nie są opłacalne.

Uwagi dotyczące przepływu ROPC

W usłudze Azure Active Directory B2C (Azure AD B2C) są obsługiwane następujące opcje:

Klient natywny: interakcja użytkownika podczas uwierzytelniania odbywa się, gdy kod jest uruchamiany na urządzeniu po stronie użytkownika. Urządzenie może być aplikacją mobilną działającą w natywnym systemie operacyjnym, takim jak Android i iOS.
Przepływ klienta publicznego: w wywołaniu interfejsu API są wysyłane tylko poświadczenia użytkownika zebrane przez aplikację. Dane uwierzytelniające aplikacji nie są przesyłane.
Dodawanie nowych oświadczeń: zawartość tokenu identyfikatora można zmienić, aby dodać nowe oświadczenia.

Następujące przepływy nie są obsługiwane:

Serwer-serwer: system ochrony tożsamości wymaga niezawodnego adresu IP zebranego z obiektu wywołującego (klienta natywnego) w ramach interakcji. W wywołaniu interfejsu API po stronie serwera jest używany tylko adres IP serwera. W przypadku przekroczenia dynamicznego progu nieudanych uwierzytelnień system ochrony tożsamości może zidentyfikować powtarzający się adres IP jako osoba atakująca.
Przepływ poufnego klienta: identyfikator klienta aplikacji jest weryfikowany, ale tajemnica aplikacji nie jest weryfikowana.

W przypadku korzystania z przepływu ROPC należy wziąć pod uwagę następujące ograniczenia:

RopC nie działa, gdy występuje żadna przerwa w przepływie uwierzytelniania, który wymaga interakcji użytkownika. Na przykład gdy hasło wygaśnie lub trzeba je zmienić, wymagane jest uwierzytelnianie wieloskładnikowe lub gdy należy zebrać więcej informacji podczas logowania (na przykład zgoda użytkownika).
RopC obsługuje tylko konta lokalne. Użytkownicy nie mogą logować się za pomocą federacyjnych dostawców tożsamości , takich jak Microsoft, Google+, X, AD-FS lub Facebook.
Zarządzanie sesjami, w tym utrzymanie mnie zalogowanym (KMSI), nie ma zastosowania.

Rejestrowanie aplikacji

Aby zarejestrować aplikację w dzierżawie usługi Azure AD B2C, możesz użyć naszego nowego ujednoliconego środowiska Rejestracje aplikacji lub starszego środowiska Aplikacje (Starsza wersja). Dowiedz się więcej o nowym środowisku.

Rejestracje aplikacji
Aplikacje (starsza wersja)

Zaloguj się do witryny Azure Portal.
Upewnij się, że używasz katalogu zawierającego instancję usługi Azure AD B2C.
1. Wybierz ikonę Katalogi i subskrypcje na pasku narzędzi portalu.
2. W ustawieniach portalu | Strona Katalogi i subskrypcje , znajdź katalog usługi Azure AD B2C na liście Nazwa katalogu, a następnie wybierz pozycję Przełącz.
W witrynie Azure Portal wyszukaj i wybierz pozycję Azure AD B2C
Wybierz pozycję Rejestracje aplikacji, a następnie wybierz pozycję Nowa rejestracja.
Wprowadź nazwę aplikacji. Na przykład ROPC_Auth_app.
Pozostaw pozostałe wartości w ich postaci, a następnie wybierz pozycję Zarejestruj.
Zarejestruj identyfikator aplikacji (klienta) do użycia w późniejszym kroku.
W obszarze Zarządzanie wybierz pozycję Uwierzytelnianie.
Wybierz pozycję Wypróbuj nowe środowisko (jeśli jest wyświetlane).
W obszarze Ustawienia zaawansowane, a w sekcji Włącz następujące przepływy mobilne i stacjonarne wybierz pozycję Tak, aby traktować aplikację jako klienta publicznego. To ustawienie jest wymagane dla procesu ROPC.
Wybierz Zapisz.
W menu po lewej stronie wybierz pozycję Manifest , aby otworzyć edytor manifestu.
Ustaw atrybut oauth2AllowImplicitFlow na true. Jeśli atrybut nie istnieje, dodaj go:
```
"oauth2AllowImplicitFlow": true,
```
Wybierz Zapisz.

Utwórz przepływ dla właściciela zasobu

Zaloguj się do portalu Azure jako Administrator Przepływu Użytkownika Identyfikatora Zewnętrznego dzierżawy usługi Azure AD B2C.
Jeśli masz dostęp do wielu dzierżaw, wybierz ikonę Ustawienia w górnym menu, aby przełączyć się na dzierżawę Azure AD B2C z menu Katalogi + subskrypcje.
W witrynie Azure Portal wyszukaj i wybierz pozycję Azure AD B2C.
Wybierz pozycję Przepływy użytkownika i wybierz pozycję Nowy przepływ użytkownika.
Wybierz Zaloguj się przy użyciu poświadczeń hasła właściciela zasobu (ROPC).
W obszarze Wersja upewnij się, że jest zaznaczona opcja Wersja zapoznawcza , a następnie wybierz pozycję Utwórz.
Podaj nazwę przepływu użytkownika, taką jak ROPC_Auth.
W obszarze Oświadczenia aplikacji wybierz pozycję Pokaż więcej.
Wybierz wymagane dla aplikacji typy roszczeń, takie jak nazwa wyświetlana, adres e-mail i dostawca tożsamości.
Wybierz przycisk OK, a następnie wybierz pozycję Utwórz.

Warunek wstępny

Jeśli nie zostało to zrobione, dowiedz się, jak używać niestandardowego pakietu startowego zasad w temacie Wprowadzenie do zasad niestandardowych w usłudze Active Directory B2C.

Tworzenie zasad właściciela zasobu

Otwórz plik TrustFrameworkExtensions.xml .

W elemecie BuildingBlocks znajdź element ClaimsSchema , a następnie dodaj następujące typy oświadczeń:

<ClaimsSchema>
  <ClaimType Id="logonIdentifier">
    <DisplayName>User name or email address that the user can use to sign in</DisplayName>
    <DataType>string</DataType>
  </ClaimType>
  <ClaimType Id="resource">
    <DisplayName>The resource parameter passes to the ROPC endpoint</DisplayName>
    <DataType>string</DataType>
  </ClaimType>
  <ClaimType Id="refreshTokenIssuedOnDateTime">
    <DisplayName>An internal parameter used to determine whether the user should be permitted to authenticate again using their existing refresh token.</DisplayName>
    <DataType>string</DataType>
  </ClaimType>
  <ClaimType Id="refreshTokensValidFromDateTime">
    <DisplayName>An internal parameter used to determine whether the user should be permitted to authenticate again using their existing refresh token.</DisplayName>
    <DataType>string</DataType>
  </ClaimType>
</ClaimsSchema>

Po dodaniu elementu ClaimsSchema dodaj element ClaimsTransformations i jego elementy podrzędne do elementu BuildingBlocks :

<ClaimsTransformations>
  <ClaimsTransformation Id="CreateSubjectClaimFromObjectID" TransformationMethod="CreateStringClaim">
    <InputParameters>
      <InputParameter Id="value" DataType="string" Value="Not supported currently. Use oid claim." />
    </InputParameters>
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="sub" TransformationClaimType="createdClaim" />
    </OutputClaims>
  </ClaimsTransformation>

  <ClaimsTransformation Id="AssertRefreshTokenIssuedLaterThanValidFromDate" TransformationMethod="AssertDateTimeIsGreaterThan">
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="refreshTokenIssuedOnDateTime" TransformationClaimType="leftOperand" />
      <InputClaim ClaimTypeReferenceId="refreshTokensValidFromDateTime" TransformationClaimType="rightOperand" />
    </InputClaims>
    <InputParameters>
      <InputParameter Id="AssertIfEqualTo" DataType="boolean" Value="false" />
      <InputParameter Id="AssertIfRightOperandIsNotPresent" DataType="boolean" Value="true" />
    </InputParameters>
  </ClaimsTransformation>
</ClaimsTransformations>

Znajdź element ClaimsProvider, który ma DisplayName określony jako Local Account SignIn, a następnie dodaj następujący profil techniczny:

<TechnicalProfile Id="ResourceOwnerPasswordCredentials-OAUTH2">
  <DisplayName>Local Account SignIn</DisplayName>
  <Protocol Name="OpenIdConnect" />
  <Metadata>
    <Item Key="UserMessageIfClaimsPrincipalDoesNotExist">We can't seem to find your account</Item>
    <Item Key="UserMessageIfInvalidPassword">Your password is incorrect</Item>
    <Item Key="UserMessageIfOldPasswordUsed">Looks like you used an old password</Item>
    <Item Key="DiscoverMetadataByTokenIssuer">true</Item>
    <Item Key="ValidTokenIssuerPrefixes">https://sts.windows.net/</Item>
    <Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
    <Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
    <Item Key="response_types">id_token</Item>
    <Item Key="response_mode">query</Item>
    <Item Key="scope">email openid</Item>
    <Item Key="grant_type">password</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="logonIdentifier" PartnerClaimType="username" Required="true" DefaultValue="{OIDC:Username}"/>
    <InputClaim ClaimTypeReferenceId="password" Required="true" DefaultValue="{OIDC:Password}" />
    <InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" />
    <InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" />
    <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
    <InputClaim ClaimTypeReferenceId="client_id" DefaultValue="ProxyIdentityExperienceFrameworkAppId" />
    <InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="IdentityExperienceFrameworkAppId" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="upn" />
  </OutputClaims>
  <OutputClaimsTransformations>
    <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromObjectID" />
  </OutputClaimsTransformations>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Zastąp wartość DefaultValueclient_id identyfikatorem aplikacji ProxyIdentityExperienceFramework utworzonej w samouczku dotyczącym wymagań wstępnych. Następnie zastąp wartość domyślną DefaultValue parametru resource_id identyfikatorem aplikacji IdentityExperienceFramework, którą również utworzyłeś w samouczku wstępnym.

Dodaj następujące elementy ClaimsProvider z ich profilami technicznymi do elementu ClaimsProviders :

<ClaimsProvider>
  <DisplayName>Azure Active Directory</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="AAD-UserReadUsingObjectId-CheckRefreshTokenDate">
      <Metadata>
        <Item Key="Operation">Read</Item>
        <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
      </Metadata>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="objectId" Required="true" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="objectId" />
        <OutputClaim ClaimTypeReferenceId="refreshTokensValidFromDateTime" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="AssertRefreshTokenIssuedLaterThanValidFromDate" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromObjectID" />
      </OutputClaimsTransformations>
      <IncludeTechnicalProfile ReferenceId="AAD-Common" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

<ClaimsProvider>
  <DisplayName>Session Management</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SM-RefreshTokenReadAndSetup">
      <DisplayName>Trustframework Policy Engine Refresh Token Setup Technical Profile</DisplayName>
      <Protocol Name="None" />
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="objectId" />
        <OutputClaim ClaimTypeReferenceId="refreshTokenIssuedOnDateTime" />
      </OutputClaims>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="JwtIssuer">
      <Metadata>
        <!-- Point to the redeem refresh token user journey-->
        <Item Key="RefreshTokenUserJourneyId">ResourceOwnerPasswordCredentials-RedeemRefreshToken</Item>
      </Metadata>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Dodaj element UserJourneys i jego elementy podrzędne do elementu TrustFrameworkPolicy :

<UserJourney Id="ResourceOwnerPasswordCredentials">
  <PreserveOriginalAssertion>false</PreserveOriginalAssertion>
  <OrchestrationSteps>
    <OrchestrationStep Order="1" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="ResourceOwnerFlow" TechnicalProfileReferenceId="ResourceOwnerPasswordCredentials-OAUTH2" />
      </ClaimsExchanges>
    </OrchestrationStep>
    <OrchestrationStep Order="2" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
      </ClaimsExchanges>
    </OrchestrationStep>
    <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
  </OrchestrationSteps>
</UserJourney>
<UserJourney Id="ResourceOwnerPasswordCredentials-RedeemRefreshToken">
  <PreserveOriginalAssertion>false</PreserveOriginalAssertion>
  <OrchestrationSteps>
    <OrchestrationStep Order="1" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="RefreshTokenSetupExchange" TechnicalProfileReferenceId="SM-RefreshTokenReadAndSetup" />
      </ClaimsExchanges>
    </OrchestrationStep>
    <OrchestrationStep Order="2" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="CheckRefreshTokenDateFromAadExchange" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId-CheckRefreshTokenDate" />
      </ClaimsExchanges>
    </OrchestrationStep>
    <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
  </OrchestrationSteps>
</UserJourney>

Na stronie Zasady niestandardowe w dzierżawie usługi Azure AD B2C wybierz pozycję Prześlij zasady.
Włącz opcję Zastąp zasady, jeśli istnieją, a następnie przejdź do pliku TrustFrameworkExtensions.xml i go wybierz.
Wybierz pozycję Prześlij.

Tworzenie pliku jednostki uzależnionej

Następnie zaktualizuj plik jednostki uzależnionej, który inicjuje utworzoną podróż użytkownika:

Utwórz kopię pliku SignUpOrSignin.xml w katalogu roboczym i zmień jego nazwę na ROPC_Auth.xml.
Otwórz nowy plik i zmień wartość atrybutu PolicyId właściwości TrustFrameworkPolicy na unikatową wartość. Identyfikator polityki to nazwa polityki. Na przykład B2C_1A_ROPC_Auth.
Zmień wartość atrybutu ReferenceId w defaultUserJourney na ResourceOwnerPasswordCredentials.

Zmień element OutputClaims tak, aby zawierał tylko następujące oświadczenia:

<OutputClaim ClaimTypeReferenceId="sub" />
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="displayName" DefaultValue="" />
<OutputClaim ClaimTypeReferenceId="givenName" DefaultValue="" />
<OutputClaim ClaimTypeReferenceId="surname" DefaultValue="" />

Na stronie Zasady niestandardowe w dzierżawie usługi Azure AD B2C wybierz pozycję Prześlij zasady.
Włącz opcję Zastąp zasady, jeśli istnieją, a następnie przejdź do i wybierz plik ROPC_Auth.xml .
Wybierz pozycję Prześlij.

Testowanie przepływu ROPC

Użyj ulubionej aplikacji do tworzenia interfejsów API, aby wygenerować wywołanie interfejsu API i przejrzeć odpowiedź, aby debugować swoją politykę. Skonstruuj wywołanie podobne do tego przykładu z następującymi informacjami jako treścią żądania POST:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token

Zastąp <tenant-name> nazwą dzierżawy usługi Azure AD B2C.
Zastąp B2C_1A_ROPC_Auth pełną nazwą polityki poświadczeń hasła właściciela zasobu.

Klawisz	Wartość
nazwa użytkownika	`user-account`
hasło	`password1`
typ_grantu	hasło
zakres	openid `application-id` offline_access
identyfikator_klienta	`application-id`
typ_odpowiedzi	Token id_token

Zastąp user-account nazwą konta użytkownika w Twoim dzierżawcy.
Zastąp password1 hasłem konta użytkownika.
Zastąp application-id identyfikatorem aplikacji z rejestracji ROPC_Auth_app.
Offline_access jest opcjonalne, jeśli chcesz otrzymać token odświeżania.

Rzeczywiste żądanie POST wygląda podobnie do następującego przykładu:

POST /<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded

username=contosouser.outlook.com.ws&password=Passxword1&grant_type=password&scope=openid+00001111-aaaa-2222-bbbb-3333cccc4444+offline_access&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&response_type=token+id_token

Pomyślna odpowiedź z dostępem w trybie offline wygląda następująco:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik9YQjNhdTNScWhUQWN6R0RWZDM5djNpTmlyTWhqN2wxMjIySnh6TmgwRlki...",
    "token_type": "Bearer",
    "expires_in": "3600",
    "refresh_token": "eyJraWQiOiJacW9pQlp2TW5pYVc2MUY0TnlfR3REVk1EVFBLbUJLb0FUcWQ1ZWFja1hBIiwidmVyIjoiMS4wIiwiemlwIjoiRGVmbGF0ZSIsInNlciI6Ij...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik9YQjNhdTNScWhUQWN6R0RWZDM5djNpTmlyTWhqN2wxMjIySnh6TmgwRlki..."
}

Zamiana tokenu odświeżania

Skonstruuj wywołanie POST podobne do pokazanego tutaj. Użyj informacji w poniższej tabeli jako treści żądania:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token

Zastąp <tenant-name> nazwą dzierżawy usługi Azure AD B2C.
Zastąp B2C_1A_ROPC_Auth pełną nazwą polityki poświadczeń hasła właściciela zasobu.

Klawisz	Wartość
typ_grantu	token odświeżania
typ_odpowiedzi	token identyfikacyjny
identyfikator_klienta	`application-id`
zasób	`application-id`
token odświeżania	`refresh-token`

Zastąp application-id identyfikatorem aplikacji z rejestracji ROPC_Auth_app.
Zastąp refresh-token na refresh_token, który został wysłany z powrotem w poprzedniej odpowiedzi.

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

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1jNTdkTzZRR1RWQndhT...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1jNTdkTzZRR1RWQn...",
    "token_type": "Bearer",
    "not_before": 1533672990,
    "expires_in": 3600,
    "expires_on": 1533676590,
    "resource": "bef2222d56-552f-4a5b-b90a-1988a7d634c3",
    "id_token_expires_in": 3600,
    "profile_info": "eyJ2ZXIiOiIxLjAiLCJ0aWQiOiI1MTZmYzA2NS1mZjM2LTRiOTMtYWE1YS1kNmVlZGE3Y2JhYzgiLCJzdWIiOm51bGwsIm5hbWUiOiJEYXZpZE11IiwicHJlZmVycmVkX3VzZXJuYW1lIjpudWxsLCJpZHAiOiJMb2NhbEFjY291bnQifQ",
    "refresh_token": "eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMCIsInppcCI6IkRlZmxhdGUiLCJzZXIiOiIxLjAi...",
    "refresh_token_expires_in": 1209600
}

Rozwiązywanie problemów

Podana aplikacja nie jest skonfigurowana tak, aby zezwalała na niejawny przepływ "OAuth"

Objaw — uruchamiasz przepływ ROPC i otrzymujesz następujący komunikat: AADB2C90057: Podana aplikacja nie jest skonfigurowana tak, aby zezwalała na niejawny przepływ OAuth.
Możliwe przyczyny — niejawny przepływ nie jest dozwolony dla aplikacji.
Rozwiązanie: Podczas tworzenia rejestracji aplikacji w usłudze Azure AD B2C należy ręcznie edytować manifest aplikacji i ustawić wartość oauth2AllowImplicitFlow właściwości na true. Po skonfigurowaniu oauth2AllowImplicitFlow właściwości może upłynąć kilka minut (zazwyczaj nie więcej niż pięć), aby zmiana weszła w życie.

Używanie natywnego pakietu SDK lub App-Auth

Usługa Azure AD B2C spełnia standardy protokołu OAuth 2.0 dla poświadczeń hasła właściciela zasobu klienta publicznego i powinny być zgodne z większością zestawów SDK klienta. Najnowsze informacje można znaleźć w temacie SDK aplikacji natywnych dla OAuth 2.0 i OpenID Connect wdrażających nowoczesne najlepsze praktyki.