Dodawanie łączników interfejsu API w celu rejestrowania przepływów użytkowników

2025-04-22

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.

Jako deweloper lub administrator IT możesz użyć łączników interfejsu API, aby zintegrować przepływy użytkowników rejestracji z interfejsami API REST, aby dostosować środowisko rejestracji i zintegrować je z systemami zewnętrznymi. Na końcu tego przewodnika będziesz mógł utworzyć przepływ użytkownika usługi Azure AD B2C, który współdziała z usługami interfejsu API REST do modyfikacji doświadczeń rejestracyjnych.

Punkt końcowy interfejsu API można utworzyć przy użyciu jednego z naszych przykładów.

W tym scenariuszu dodamy możliwość wprowadzenia numeru lojalnościowego dla użytkowników na stronie rejestracji usługi Azure AD B2C. Interfejs API REST sprawdza, czy kombinacja wiadomości e-mail i numeru lojalnościowego jest mapowana na kod promocyjny. Jeśli interfejs API REST znajdzie kod promocyjny dla tego użytkownika, zostanie zwrócony do usługi Azure AD B2C. Na koniec kod promocyjny zostanie wstawiony do roszczeń tokenu do wykorzystania przez aplikację.

Możesz również zaprojektować interakcję jako krok aranżacji. Jest to odpowiednie, gdy interfejs API REST nie będzie weryfikował danych na ekranie i zawsze zwraca oświadczenia. Aby uzyskać więcej informacji, zobacz Walkthrough: Integrate REST API claims exchanges in your Azure AD B2C user journey as an orchestration step (Przewodnik: integrowanie wymiany oświadczeń interfejsu API REST w podróży użytkownika usługi Azure AD B2C jako krok aranżacji).

Wymagania wstępne

Utwórz przepływ użytkownika, aby użytkownicy mogli zarejestrować się i zalogować do aplikacji.
Rejestrowanie aplikacji internetowej.

Wykonaj kroki opisane w Jak rozpocząć z zasadami niestandardowymi w usłudze Active Directory B2C. W tym samouczku przedstawiono sposób aktualizowania niestandardowych plików zasad, aby korzystać z konfiguracji kont usługi Azure AD B2C.
Rejestrowanie aplikacji internetowej.

Tworzenie łącznika interfejsu API

Aby użyć łącznika API, należy najpierw go utworzyć, a następnie włączyć w przepływie użytkownika.

Zaloguj się do witryny Azure Portal.
W obszarze usługi Azurewybierz Azure AD B2C.
Wybierz pozycję Łączniki interfejsu API, a następnie wybierz pozycję Nowy łącznik interfejsu API.
Podaj nazwę wyświetlaną wywołania. Na przykład zweryfikuj informacje o użytkowniku.
Podaj adres URL punktu końcowego dla wywołania interfejsu API.
Wybierz typ uwierzytelniania i skonfiguruj informacje uwierzytelniania na potrzeby wywoływania interfejsu API. Dowiedz się, jak zabezpieczyć łącznik interfejsu API.
Wybierz Zapisz.

Żądanie wysłano do Twojego API

Łącznik interfejsu API przyjmuje formę żądania HTTP POST, wysyłając atrybuty użytkownika ('roszczenia') jako pary klucz-wartość w ciele JSON. Atrybuty są serializowane podobnie jak właściwości użytkownika programu Microsoft Graph .

Przykładowe żądanie

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "<step-name>",
 "client_id":"00001111-aaaa-2222-bbbb-3333cccc4444",
 "ui_locales":"en-US"
}

W żądaniu można wysyłać tylko właściwości użytkownika i atrybuty niestandardowe wymienione w środowiskuatrybutów użytkownika>.

Atrybuty niestandardowe istnieją w formacie extension_<extensions-app-id>_CustomAttribute w katalogu. Interfejs API powinien oczekiwać otrzymania oświadczeń w tym samym formacie serializowanym. Aby uzyskać więcej informacji na temat atrybutów niestandardowych, zobacz Definiowanie atrybutów niestandardowych w usłudze Azure AD B2C.

Ponadto te oświadczenia są zwykle wysyłane we wszystkich żądaniach:

Ustawienia regionalne interfejsu użytkownika ('ui_locales') — ustawienia regionalne użytkownika końcowego skonfigurowane na urządzeniu. Może to być używane przez interfejs API do zwracania międzynarodowych odpowiedzi.
Krok ('krok') — krok lub punkt przepływu użytkownika wywoływanego przez łącznik interfejsu API. Wartości obejmują:
- PostFederationSignup — odpowiada "Po sfederowaniu z dostawcą tożsamości podczas rejestracji"
- PostAttributeCollection — odpowiada "Przed utworzeniem użytkownika"
- PreTokenIssuance — odpowiada "Przed wysłaniem tokenu (wersja zapoznawcza)". Dowiedz się więcej o tym kroku
Identyfikator klienta ('client_id') — appId wartość aplikacji uwierzytelnianej przez użytkownika końcowego w przepływie użytkownika. To nie jest element aplikacji zasobów appId w tokenach dostępu.
Adres e-mail ('adres e-mail') lub tożsamości ('tożsamości') — te oświadczenia mogą być używane przez interfejs API do identyfikowania użytkownika końcowego, który uwierzytelnia się do aplikacji.

Ważne

Jeśli oświadczenie nie ma wartości w momencie wywołania punktu końcowego interfejsu API, oświadczenie nie zostanie wysłane do interfejsu API. Interfejs API powinien być zaprojektowany tak, aby jawnie sprawdzać i obsługiwać przypadek, w którym oświadczenie nie znajduje się w żądaniu.

Włączanie łącznika interfejsu API w przepływie użytkownika

Wykonaj następujące kroki, aby dodać łącznik interfejsu API do przepływu użytkownika rejestracji.

Zaloguj się do witryny Azure Portal.
W obszarze usługi Azurewybierz Azure AD B2C.
Wybierz pozycję Przepływy użytkownika, a następnie wybierz przepływ użytkownika, do którego chcesz dodać łącznik interfejsu API.
Wybierz pozycję Łączniki interfejsu API, a następnie wybierz punkty końcowe interfejsu API, które chcesz wywołać, wykonując następujące kroki w przepływie użytkownika:
- Po sfederowaniu z dostawcą tożsamości podczas rejestracji
- Przed utworzeniem użytkownika
- Przed wysłaniem tokenu (wersja zapoznawcza)
Wybierz Zapisz.

Te kroki są dostępne tylko dla rejestracji i logowania (zalecane) oraz rejestracji (zalecane), ale mają zastosowanie tylko do części procesu rejestracji w doświadczeniu.

Łącznik interfejsu API w tym kroku w procesie rejestracji jest wywoływany natychmiast po uwierzytelnieniu użytkownika za pomocą dostawcy tożsamości (takiego jak Google, Facebook i Microsoft Entra ID). Ten krok poprzedza stronę kolekcji atrybutów, która jest formularzem przedstawionym użytkownikowi w celu zbierania atrybutów użytkownika. Ten krok nie jest wywoływany, jeśli użytkownik rejestruje się przy użyciu konta lokalnego.

Przykładowe żądanie wysłane do interfejsu API w tym kroku

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [ 
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "step": "PostFederationSignup",
 "client_id":"<guid>",
 "ui_locales":"en-US"
}

Dokładne oświadczenia wysyłane do interfejsu API zależą od informacji dostarczonych przez dostawcę tożsamości. Wiadomość e-mail zawsze jest wysyłana.

Oczekiwane typy odpowiedzi z internetowego interfejsu API na tym etapie

Gdy internetowy interfejs API odbiera żądanie HTTP z identyfikatora Entra firmy Microsoft podczas przepływu użytkownika, może zwrócić następujące odpowiedzi:

Kontynuacja odpowiedzi
Odpowiedź blokująca

Kontynuacja odpowiedzi

Odpowiedź kontynuacji wskazuje, że przepływ użytkownika powinien przejść do następnego kroku: strony kolekcji atrybutów.

W odpowiedzi na dalsze zapytania interfejs API może zwracać oświadczenia. Jeśli oświadczenie jest zwracane przez interfejs API, oświadczenie wykonuje następujące czynności:

Wstępnie wypełnia pole wejściowe na stronie kolekcji atrybutów.

Zobacz przykład odpowiedzi kontynuacji.

Odpowiedź blokująca

Blokująca odpowiedź kończy przepływ użytkownika. Interfejs API może celowo wydać go, aby zatrzymać kontynuację przepływu użytkownika, wyświetlając użytkownikowi stronę bloku. Na stronie bloku zostanie wyświetlona userMessage wartość podana przez interfejs API.

Zobacz przykład odpowiedzi blokującej.

Przed utworzeniem użytkownika

Łącznik API na tym etapie procesu rejestracji jest wywoływany po stronie zbierania atrybutów, jeżeli takowa została uwzględniona. Ten krok jest zawsze wywoływany przed utworzeniem konta użytkownika.

Przykładowe żądanie wysłane do interfejsu API w tym kroku

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "PostAttributeCollection",
 "client_id":"00001111-aaaa-2222-bbbb-3333cccc4444",
 "ui_locales":"en-US"
}

Oświadczenia wysyłane do interfejsu API zależą od informacji zbieranych od użytkownika lub udostępniane przez dostawcę tożsamości.

Oczekiwane typy odpowiedzi z internetowego interfejsu API na tym etapie

Gdy internetowy interfejs API odbiera żądanie HTTP z identyfikatora Entra firmy Microsoft podczas przepływu użytkownika, może zwrócić następujące odpowiedzi:

Kontynuacja odpowiedzi
Odpowiedź blokująca
Odpowiedź na walidację

Kontynuacja odpowiedzi

Odpowiedź wskazująca na kontynuację oznacza, że proces użytkownika powinien przejść do następnego kroku: utworzenie użytkownika w katalogu.

W odpowiedzi na dalsze zapytania interfejs API może zwracać oświadczenia. Jeśli oświadczenie jest zwracane przez interfejs API, oświadczenie wykonuje następujące czynności:

Zastępuje wszystkie wartości, które zostały już udostępnione przez użytkownika na stronie kolekcji atrybutów.

Aby zarejestrować oświadczenia w katalogu podczas rejestracji, które nie powinny być zbierane od użytkownika, nadal należy wybrać oświadczenia w obszarze Atrybuty użytkownika przepływu użytkownika, co domyślnie prosi o wartości, ale można użyć własnego kodu JavaScript lub CSS, aby ukryć pola wejściowe przed użytkownikiem końcowym.

Zobacz przykład odpowiedzi kontynuacji.

Odpowiedź blokująca

Zobacz przykład odpowiedzi blokującej.

Odpowiedź na błąd walidacji

Gdy interfejs API odpowie odpowiedzią na błąd weryfikacji, przepływ użytkownika pozostaje na stronie zbierania atrybutów i userMessage jest wyświetlany użytkownikowi. Użytkownik może następnie edytować i ponownie przesłać formularz. Tego typu odpowiedzi można użyć do weryfikacji danych wejściowych.

Zobacz przykład odpowiedzi na błąd weryfikacji.

Przed wysłaniem tokenu (wersja zapoznawcza)

Ważne

Łączniki interfejsu API używane w tym kroku są w wersji zapoznawczej. Aby uzyskać więcej informacji na temat wersji zapoznawczych, zobacz Warunki dotyczące produktów dla usług online.

Konektor API na tym etapie jest wywoływany, gdy token ma zostać wystawiony podczas rejestracji lub logowania. Łącznik API dla tego kroku może być użyty do wzbogacenia tokenu wartościami roszczeń z zewnętrznych źródeł.

Przykładowe żądanie wysłane do interfejsu API w tym kroku

POST <API-endpoint>
Content-type: application/json

{
 "clientId": "11112222-bbbb-3333-cccc-4444dddd5555",
 "step": "PreTokenApplicationClaims",
 "ui_locales":"en-US",
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
}

Oświadczenia wysyłane do interfejsu API zależą od informacji zdefiniowanych dla użytkownika.

Oczekiwane typy odpowiedzi z internetowego interfejsu API na tym etapie

Gdy internetowy interfejs API odbiera żądanie HTTP z identyfikatora Entra firmy Microsoft podczas przepływu użytkownika, może zwrócić następujące odpowiedzi:

Kontynuacja odpowiedzi

Kontynuacja odpowiedzi

Odpowiedź kontynuacji wskazuje, że przepływ użytkownika powinien przejść dalej do następnego kroku: wydanie tokenu.

W odpowiedzi ciągłej interfejs API może zwrócić dodatkowe oświadczenia. Oświadczenie zwrócone przez interfejs API, które chcesz zwrócić w tokenie, musi być wbudowanym roszczeniem lub zdefiniowane jako atrybut niestandardowy i musi zostać wybrane w konfiguracji roszczeń aplikacji przepływu użytkownika.

Wartość oświadczenia w tokenie będzie wartością zwracaną przez interfejs API, a nie wartością w katalogu. Niektóre wartości oświadczeń nie mogą zostać nadpisane przez odpowiedź interfejsu API. Oświadczenia, które mogą być zwracane przez interfejs API, odpowiadają zestawowi znalezionemu w obszarze Atrybuty użytkownika z wyjątkiem email.

Zobacz przykład odpowiedzi kontynuacji.

Uwaga / Notatka

Interfejs API jest wywoływany tylko podczas początkowego uwierzytelniania. W przypadku używania tokenów odświeżania do cichego uzyskiwania nowych tokenów dostępu lub identyfikacyjnych, token będzie zawierać wartości oceniane podczas początkowego uwierzytelniania.

Przykładowe odpowiedzi

Przykład kontynuacji odpowiedzi

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "Continue",
    "postalCode": "12349", // return claim
    "extension_<extensions-app-id>_CustomAttribute": "value" // return claim
}

Parametr	Typ	Wymagane	Opis
wersja	Sznurek	Tak	Wersja twojego interfejsu API.
akcja	Sznurek	Tak	Wartość musi mieć wartość `Continue`.
<wbudowanyAtrybutUżytkownika>	<typ-atrybutu>	Nie.	Zwrócone wartości mogą zastępować wartości zebrane od użytkownika.
<extension_{identyfikator-aplikacji-rozszerzeń}_CustomAttribute>	<typ-atrybutu>	Nie.	Oświadczenie nie musi zawierać `_<extensions-app-id>_`elementu , jest opcjonalne. Zwrócone wartości mogą zastępować wartości zebrane od użytkownika.

Przykład odpowiedzi blokującej

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "ShowBlockPage",
    "userMessage": "There was a problem with your request. You are not able to sign up at this time. Please contact your system administrator",
}

Parametr	Typ	Wymagane	Opis
wersja	Sznurek	Tak	Wersja twojego interfejsu API.
akcja	Sznurek	Tak	Wartość musi być `ShowBlockPage`
wiadomość użytkownika	Sznurek	Tak	Komunikat wyświetlany użytkownikowi.

Doświadczenie użytkownika końcowego z zablokowaną odpowiedzią

Przykład odpowiedzi blokującej

Przykład odpowiedzi na błąd weryfikacji

HTTP/1.1 400 Bad Request
Content-type: application/json

{
    "version": "1.0.0",
    "status": 400,
    "action": "ValidationError",
    "userMessage": "Please enter a valid Postal Code."
}

Parametr	Typ	Wymagane	Opis
wersja	Sznurek	Tak	Wersja twojego interfejsu API.
akcja	Sznurek	Tak	Wartość musi mieć wartość `ValidationError`.
stan	Liczba całkowita / ciąg znaków	Tak	Musi być wartością `400`lub `"400"` w przypadku odpowiedzi ValidationError.
wiadomość użytkownika	Sznurek	Tak	Komunikat wyświetlany użytkownikowi.

Uwaga / Notatka

Kod stanu HTTP musi być "400" oprócz wartości "status" w treści odpowiedzi.

Doświadczenie użytkownika końcowego z odpowiedzią na błąd weryfikacji

Przykład odpowiedzi na błąd weryfikacji

Przygotowywanie punktu końcowego interfejsu API REST

W tym przewodniku należy mieć interfejs API REST, który sprawdza, czy adres e-mail jest zarejestrowany w systemie backendowym przy użyciu ID programu lojalnościowego. W przypadku zarejestrowania interfejs API REST powinien zwrócić kod promocji rejestracji, którego klient może użyć do zakupu towarów w aplikacji. W przeciwnym razie interfejs API REST powinien zwrócić komunikat o błędzie HTTP 409: "Identyfikator lojalnościowy {identyfikator lojalności}" nie jest skojarzony z adresem e-mail {email}".

Poniższy kod JSON ilustruje dane, które usługa Azure AD B2C wyśle do punktu końcowego interfejsu API REST.

{
    "email": "User email address",
    "language": "Current UI language",
    "loyaltyId": "User loyalty ID"
}

Gdy interfejs API REST zweryfikuje dane, musi zwrócić kod HTTP 200 (OK) z następującymi danymi JSON:

{
    "promoCode": "24534"
}

Jeśli walidacja nie powiodła się, interfejs API REST musi zwrócić HTTP 409 (Conflict) z JSON elementem userMessage. IEF oczekuje userMessage żądania, które interfejs API REST zwraca. To oświadczenie zostanie przedstawione użytkownikowi jako ciąg, jeśli walidacja zakończy się niepowodzeniem.

{
    "version": "1.0.1",
    "status": 409,
    "userMessage": "LoyaltyId ID '1234' is not associated with 'david@contoso.com' email address."
}

Konfiguracja punktu końcowego interfejsu API REST wykracza poza zakres tego artykułu. Utworzyliśmy przykład usługi Azure Functions . Pełny kod funkcji platformy Azure można uzyskać w witrynie GitHub.

Definiowanie oświadczeń

Roszczenie zapewnia tymczasowe przechowywanie danych podczas wykonywania polityki usługi Azure AD B2C. Oświadczenia można zadeklarować w sekcji schematu oświadczeń .

Otwórz plik rozszerzeń zasad. Na przykład SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
Wyszukaj element BuildingBlocks . Jeśli element nie istnieje, dodaj go.
Znajdź element ClaimsSchema . Jeśli element nie istnieje, dodaj go.
Dodaj następujące oświadczenia do elementu ClaimsSchema .

<ClaimType Id="loyaltyId">
  <DisplayName>Your loyalty ID</DisplayName>
  <DataType>string</DataType>
  <UserInputType>TextBox</UserInputType>
</ClaimType>
<ClaimType Id="promoCode">
  <DisplayName>Your promo code</DisplayName>
  <DataType>string</DataType>
  <UserInputType>Paragraph</UserInputType>
</ClaimType>
  <ClaimType Id="userLanguage">
  <DisplayName>User UI language (used by REST API to return localized error messages)</DisplayName>
  <DataType>string</DataType>
</ClaimType>

Dodawanie profilu technicznego interfejsu API RESTful

Profil techniczny RESTful zapewnia obsługę współdziałania z własną usługą RESTful. Usługa Azure AD B2C wysyła dane do usługi RESTful w InputClaims kolekcji i odbiera je z powrotem w OutputClaims kolekcji. Znajdź element ClaimsProviders i dodaj nowego dostawcę oświadczeń w następujący sposób:

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-ValidateProfile">
      <DisplayName>Check loyaltyId Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <!-- Set the ServiceUrl with your own REST API endpoint -->
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/ValidateProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <!-- Set AuthenticationType to Basic or ClientCertificate in production environments -->
        <Item Key="AuthenticationType">None</Item>
        <!-- REMOVE the following line in production environments -->
        <Item Key="AllowInsecureAuthInProduction">true</Item>
      </Metadata>
      <InputClaims>
        <!-- Claims sent to your REST API -->
        <InputClaim ClaimTypeReferenceId="loyaltyId" />
        <InputClaim ClaimTypeReferenceId="email" />
        <InputClaim ClaimTypeReferenceId="userLanguage" PartnerClaimType="lang" DefaultValue="{Culture:LCID}" AlwaysUseDefaultValue="true" />
      </InputClaims>
      <OutputClaims>
        <!-- Claims parsed from your REST API -->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

W tym przykładzie userLanguage zostanie wysłany do usługi REST jako lang w danych JSON. Wartość userLanguage oświadczenia zawiera bieżący identyfikator języka użytkownika. Aby uzyskać więcej informacji, zobacz moduł rozstrzygania roszczeń.

Konfigurowanie profilu technicznego interfejsu API RESTful

Po wdrożeniu interfejsu API REST, ustawienia metadanych profilu technicznego REST-ValidateProfile powinny odzwierciedlać własny interfejs API REST, w tym:

Adres URL usługi. Ustaw adres URL punktu końcowego interfejsu API REST.
Wyślij ClaimsIn. Określ sposób wysyłania oświadczeń wejściowych do dostawcy oświadczeń RESTful.
Typ uwierzytelniania. Ustaw typ uwierzytelniania wykonywanego przez dostawcę oświadczeń RESTful.
AllowInsecureAuthInProduction. W środowisku produkcyjnym upewnij się, że ustawiono te metadane na true

Zobacz metadane profilu technicznego RESTful, aby uzyskać więcej konfiguracji.

Komentarze powyżej AuthenticationType i AllowInsecureAuthInProduction określają zmiany, które należy wprowadzić podczas przechodzenia do środowiska produkcyjnego. Aby dowiedzieć się, jak zabezpieczyć interfejsy API RESTful dla środowiska produkcyjnego, zobacz Bezpieczny interfejs API RESTful.

Weryfikowanie danych wejściowych użytkownika

Aby uzyskać numer lojalnościowy użytkownika podczas rejestracji, musisz zezwolić użytkownikowi na wprowadzanie tych danych na ekranie. Dodaj atrybut wyjściowy loyaltyId do strony rejestracji, dodając go do istniejącego technicznego elementu profilu rejestracji OutputClaims. Określ całą listę oświadczeń wyjściowych, aby kontrolować kolejność prezentowania oświadczeń na ekranie.

Dodaj odwołanie do profilu technicznego weryfikacji do profilu technicznego rejestracji, który wywołuje element REST-ValidateProfile. Nowy profil techniczny weryfikacji zostanie dodany na początku kolekcji <ValidationTechnicalProfiles>, zdefiniowanej w podstawowej polityce. To zachowanie oznacza, że dopiero po pomyślnej weryfikacji usługa Azure AD B2C przechodzi do utworzenia konta w katalogu.

Znajdź element ClaimsProviders . Dodaj nowego dostawcę oświadczeń w następujący sposób:

<ClaimsProvider>
  <DisplayName>Local Account</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="newPassword" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="displayName"/>
        <OutputClaim ClaimTypeReferenceId="givenName"/>
        <OutputClaim ClaimTypeReferenceId="surName"/>
        <!-- Required to present the text box to collect the data from the user -->
        <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
        <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
        to subsequent orchestration steps and token issuance-->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile" />
      </ValidationTechnicalProfiles>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>
<ClaimsProvider>
  <DisplayName>Self Asserted</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SelfAsserted-Social">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="email" />
      </InputClaims>
        <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="email" />
        <OutputClaim ClaimTypeReferenceId="displayName"/>
        <OutputClaim ClaimTypeReferenceId="givenName"/>
        <OutputClaim ClaimTypeReferenceId="surname"/>
        <!-- Required to present the text box to collect the data from the user -->
        <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
        <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
        to subsequent orchestration steps and token issuance-->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile"/>
      </ValidationTechnicalProfiles>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Dołączanie oświadczenia do tokenu

Aby zwrócić oświadczenie kodu promocyjnego z powrotem do aplikacji docelowej, dodaj oświadczenie wyjściowe do pliku SocialAndLocalAccounts/SignUpOrSignIn.xml. Oświadczenie wynikowe umożliwi dodanie go do tokenu po pomyślnym zakończeniu ścieżki użytkownika i zostanie wysłane do aplikacji. Zmodyfikuj element profilu technicznego w sekcji jednostki uzależnionej, aby dodać promoCode element jako oświadczenie wyjściowe.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
      <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
      <OutputClaim ClaimTypeReferenceId="promoCode" DefaultValue="" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Przetestuj politykę niestandardową

Zaloguj się do witryny Azure Portal.
Jeśli masz dostęp do wielu tenantów, wybierz ikonę Ustawienia w górnym menu, aby przełączyć się na dzierżawę Microsoft Entra ID z menu Katalogi i subskrypcje.
Wybierz pozycję Wszystkie usługi w lewym górnym rogu witryny Azure Portal, a następnie wyszukaj i wybierz pozycję Rejestracje aplikacji.
Wybierz Identity Experience Framework.
Wybierz Prześlij zasady niestandardowe, a następnie prześlij zmienione pliki zasad: TrustFrameworkExtensions.xml, i SignUpOrSignin.xml.
Wybierz przekazane zasady rejestracji lub logowania, a następnie kliknij przycisk Uruchom teraz .
Powinno być możliwe zarejestrowanie się przy użyciu adresu e-mail.
Kliknij link Zarejestruj się teraz .
W polu Twój identyfikator lojalnościowy wpisz 1234, a następnie kliknij przycisk Kontynuuj. W tym momencie powinien zostać wyświetlony komunikat o błędzie weryfikacji.
Zmień wartość na inną, a następnie kliknij przycisk Kontynuuj.
Token wysłany z powrotem do twojej aplikacji zawiera roszczenie promoCode.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584295703,
  "nbf": 1584292103,
  "ver": "1.0",
  "iss": "https://contoso.b2clogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/",
  "aud": "22223333-cccc-4444-dddd-5555eeee6666",
  "acr": "b2c_1a_signup_signin",
  "nonce": "defaultNonce",
  "iat": 1584292103,
  "auth_time": 1584292103,
  "name": "Emily Smith",
  "email": "emily@outlook.com",
  "given_name": "Emily",
  "family_name": "Smith",
  "promoCode": "84362"
  ...
}

Najlepsze rozwiązania i sposoby rozwiązywania problemów

Korzystanie z funkcji chmury bezserwerowej

Funkcje bezserwerowe, takie jak wyzwalacze HTTP w usłudze Azure Functions, umożliwiają tworzyć punkty dostępowe interfejsu API do użycia z łącznikiem interfejsu API. Możesz użyć funkcji chmury bezserwerowej, aby na przykład wykonać logikę walidacji i ograniczyć rejestrację do określonych domen poczty e-mail. Funkcja chmury bezserwerowej może również wywoływać inne API, magazyny danych oraz inne usługi chmurowe w złożonych scenariuszach.

Najlepsze rozwiązania

Upewnij się, że:

Twój interfejs API spełnia kontrakty zapytań i odpowiedzi interfejsu API zgodnie z powyższym opisem.
Adres URL punktu końcowego łącznika interfejsu API wskazuje prawidłowy punkt końcowy interfejsu API.
Twój interfejs API jawnie sprawdza wartości null odebranych roszczeń, od których są uzależnione.
Twój interfejs API implementuje metodę uwierzytelniania opisaną w Zabezpieczaniu łącznika interfejsu API.
Interfejs API reaguje tak szybko, jak to możliwe, aby zapewnić płynne doświadczenie użytkownika.
- Usługa Azure AD B2C poczeka maksymalnie 10 sekund na odebranie odpowiedzi. Jeśli żadna z nich nie zostanie odebrana, podejmie jeszcze jedną próbę (ponów próbę) podczas wywoływania interfejsu API.
- Jeśli korzystasz z funkcji bezserwerowej lub skalowalnej usługi internetowej, użyj planu hostingu, który utrzymuje interfejs API "obudzić" lub "ciepły" w środowisku produkcyjnym. W przypadku usługi Azure Functions zaleca się użycie co najmniej planu Premium w środowisku produkcyjnym.
Zapewnij wysoką dostępność interfejsu API.
Monitorowanie i optymalizowanie wydajności podrzędnych interfejsów API, baz danych lub innych zależności interfejsu API.

Ważne

Punkty końcowe muszą być zgodne z wymaganiami dotyczącymi zabezpieczeń usługi Azure AD B2C. Starsze wersje protokołu TLS i szyfry są przestarzałe. Aby uzyskać więcej informacji, zobacz wymagania dotyczące protokołu TLS i szyfrowania usługi Azure AD B2C.

Korzystanie z rejestrowania

Ogólnie rzecz biorąc, warto używać narzędzi rejestrowania włączonych przez usługę internetowego interfejsu API, takich jak application insights, do monitorowania interfejsu API pod kątem nieoczekiwanych kodów błędów, wyjątków i niskiej wydajności.

Monitoruj kody stanu HTTP, które nie są http 200 lub 400.
Kod stanu HTTP 401 lub 403 zwykle wskazuje, że występuje problem z uwierzytelnianiem. Dokładnie sprawdź warstwę uwierzytelniania interfejsu API i odpowiednią konfigurację w łączniku API.
Jeśli to konieczne, użyj bardziej agresywnych poziomów rejestrowania (na przykład "trace" lub "debug") w trakcie rozwoju.
Monitoruj interfejs API pod kątem długich czasów odpowiedzi.

Dodatkowo, usługa Azure AD B2C rejestruje metadane dotyczące transakcji interfejsu API występujących podczas uwierzytelniania użytkowników za pośrednictwem procesu logowania użytkownika. Aby je znaleźć:

Przejdź do usługi Azure AD B2C.
Pod Aktywności wybierz Dzienniki audytu.
Filtruj widok listy: w polu Data wybierz żądany interwał czasu, a w polu Działanie wybierz pozycję Interfejs API został wywołany jako część przepływu użytkownika.
Sprawdź poszczególne dzienniki. Każdy wiersz reprezentuje łącznik interfejsu API, który próbuje zostać wywołany podczas przepływu użytkownika. Jeśli wywołanie interfejsu API zakończy się niepowodzeniem i nastąpi ponowna próba, nadal jest reprezentowana jako pojedynczy wiersz. numberOfAttempts wskazuje, ile razy wywołano twoje API. Ta wartość może być 1lub 2. Inne informacje o wywołaniu interfejsu API są szczegółowe w dziennikach.

Przykład transakcji łącznika interfejsu API podczas uwierzytelniania użytkownika

Korzystanie z funkcji chmury bezserwerowej

Funkcje chmury bezserwerowej, takie jak wyzwalacze HTTP w usłudze Azure Functions, zapewniają prosty, wysoce dostępny i wydajny sposób tworzenia punktów końcowych interfejsu API do użycia jako łączniki interfejsu API.

Najlepsze rozwiązania

Upewnij się, że:

Twój interfejs API jawnie sprawdza wartości null odebranych roszczeń, od których są uzależnione.
Twój interfejs API implementuje metodę uwierzytelniania opisaną w Zabezpieczaniu łącznika interfejsu API.
Interfejs API reaguje tak szybko, jak to możliwe, aby zapewnić płynne doświadczenie użytkownika.
- Jeśli korzystasz z funkcji bezserwerowej lub skalowalnej usługi internetowej, użyj planu hostingu, który utrzymuje interfejs API "obudzić" lub "ciepły" w środowisku produkcyjnym. W przypadku usługi Azure Functions zaleca się użycie co najmniej planu Premium
Zapewnij wysoką dostępność interfejsu API.
Monitorowanie i optymalizowanie wydajności podrzędnych interfejsów API, baz danych lub innych zależności interfejsu API.

Ważne

Korzystanie z rejestrowania

Monitoruj kody stanu HTTP, które nie są http 200 lub 400.
Kod stanu HTTP 401 lub 403 zwykle wskazuje, że występuje problem z uwierzytelnianiem. Dokładnie sprawdź warstwę uwierzytelniania interfejsu API i odpowiednią konfigurację w łączniku API.
Jeśli to konieczne, użyj bardziej agresywnych poziomów rejestrowania (na przykład "trace" lub "debug") w trakcie rozwoju.
Monitoruj interfejs API pod kątem długich czasów odpowiedzi.

Dalsze kroki

Rozpocznij pracę z naszymi przykładami.
Zabezpieczanie łącznika interfejsu API

Udostępnij za pośrednictwem

Dodawanie łącznika interfejsu API do przepływu rejestracji użytkownika

Wymagania wstępne

Tworzenie łącznika interfejsu API

Żądanie wysłano do Twojego API

Włączanie łącznika interfejsu API w przepływie użytkownika

Po połączeniu federacyjnym z dostawcą tożsamości podczas rejestracji

Przykładowe żądanie wysłane do interfejsu API w tym kroku

Oczekiwane typy odpowiedzi z internetowego interfejsu API na tym etapie

Kontynuacja odpowiedzi

Odpowiedź blokująca

Przed utworzeniem użytkownika

Przykładowe żądanie wysłane do interfejsu API w tym kroku

Oczekiwane typy odpowiedzi z internetowego interfejsu API na tym etapie

Kontynuacja odpowiedzi

Odpowiedź blokująca

Odpowiedź na błąd walidacji

Przed wysłaniem tokenu (wersja zapoznawcza)

Przykładowe żądanie wysłane do interfejsu API w tym kroku

Oczekiwane typy odpowiedzi z internetowego interfejsu API na tym etapie

Kontynuacja odpowiedzi

Przykładowe odpowiedzi

Przykład kontynuacji odpowiedzi

Przykład odpowiedzi blokującej

Przykład odpowiedzi na błąd weryfikacji

Przygotowywanie punktu końcowego interfejsu API REST

Definiowanie oświadczeń

Dodawanie profilu technicznego interfejsu API RESTful

Konfigurowanie profilu technicznego interfejsu API RESTful

Weryfikowanie danych wejściowych użytkownika

Dołączanie oświadczenia do tokenu

Przetestuj politykę niestandardową

Najlepsze rozwiązania i sposoby rozwiązywania problemów

Korzystanie z funkcji chmury bezserwerowej

Najlepsze rozwiązania

Korzystanie z rejestrowania

Korzystanie z funkcji chmury bezserwerowej

Najlepsze rozwiązania

Korzystanie z rejestrowania

Dalsze kroki

Opinia

Dodatkowe zasoby