Share via

Wzbogacanie tokenów za pomocą oświadczeń ze źródeł zewnętrznych przy użyciu łączników interfejsu API

  • Artykuł

Przed rozpoczęciem użyj selektora Wybierz typ zasad, 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.

Usługa Azure Active Directory B2C (Azure AD B2C) umożliwia deweloperom tożsamości integrowanie interakcji z interfejsem API RESTful w przepływie użytkownika przy użyciu łączników interfejsu API. Umożliwia deweloperom dynamiczne pobieranie danych z zewnętrznych źródeł tożsamości. Na końcu tego przewodnika będziesz mieć możliwość utworzenia przepływu użytkownika usługi Azure AD B2C, który współdziała z interfejsami API w celu wzbogacania tokenów z informacjami ze źródeł zewnętrznych.

Możesz użyć łączników interfejsu API zastosowanych do kroku Przed wysłaniem tokenu (wersja zapoznawcza), aby wzbogacić tokeny dla aplikacji o informacje ze źródeł zewnętrznych. Gdy użytkownik zaloguje się lub zarejestruje się, usługa Azure AD B2C wywoła punkt końcowy interfejsu API skonfigurowany w łączniku interfejsu API, który może wysyłać zapytania o informacje o użytkowniku w usługach podrzędnych, takich jak usługi w chmurze, niestandardowe magazyny użytkowników, niestandardowe systemy uprawnień, starsze systemy tożsamości i inne.

Uwaga

Ta funkcja jest dostępna w publicznej wersji zapoznawczej.

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

Wymagania wstępne

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

Tworzenie łącznika interfejsu API

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

  1. Zaloguj się w witrynie Azure Portal.

  2. W obszarze Usługi platformy Azure wybierz pozycję Azure AD B2C.

  3. Wybierz pozycję Łączniki interfejsu API, a następnie wybierz pozycję Nowy łącznik interfejsu API.

    Screenshot showing the API connectors page in the Azure portal with the New API Connector button highlighted.

  4. Podaj nazwę wyświetlaną wywołania. Na przykład wzbogacanie tokenu ze źródła zewnętrznego.

  5. Podaj adres URL punktu końcowego dla wywołania interfejsu API.

  6. Wybierz typ uwierzytelniania i skonfiguruj informacje uwierzytelniania na potrzeby wywoływania interfejsu API. Dowiedz się, jak zabezpieczyć Połączenie or interfejsu API.

    Screenshot showing sample authentication configuration for an API connector.

  7. Wybierz pozycję Zapisz.

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.

  1. Zaloguj się w witrynie Azure Portal.

  2. W obszarze Usługi platformy Azure wybierz pozycję Azure AD B2C.

  3. Wybierz pozycję Przepływy użytkownika, a następnie wybierz przepływ użytkownika, do którego chcesz dodać łącznik interfejsu API.

  4. Wybierz pozycję Łączniki interfejsu API, a następnie wybierz punkt końcowy interfejsu API, który chcesz wywołać w kroku Przed wysłaniem tokenu (wersja zapoznawcza) w przepływie użytkownika:

    Screenshot of selecting an API connector for a user flow step.

  5. Wybierz pozycję Zapisz.

Ten krok istnieje tylko w przypadku tworzenia konta i logowania (zalecane), rejestracji (zalecane) i przepływów użytkowników logowania (zalecane).

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

Łącznik interfejsu API w tym kroku jest wywoływany, gdy token ma zostać wystawiony podczas logowania i rejestracji. Łącznik interfejsu API materializuje się jako żądanie HTTP POST , wysyłając atrybuty użytkownika ('claims') jako pary klucz-wartość w treści JSON. Atrybuty są serializowane podobnie jak właściwości użytkownika programu Microsoft Graph .

POST <API-endpoint>
Content-type: application/json
{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "objectId": "ab3ec3b2-a435-45e4-b93a-56a005e88bb7",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "client_id": "231c70e8-8424-48ac-9b5d-5623b9e4ccf3",
 "step": "PreTokenIssuance",
 "ui_locales":"en-US"
}

Oświadczenia wysyłane do interfejsu API zależą od informacji zdefiniowanych dla użytkownika. W żądaniu można wysyłać tylko właściwości użytkownika i atrybuty niestandardowe wymienione w środowisku atrybutów użytkownika usługi Azure AD B2C>. 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 dotyczących tego kroku:

  • 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ść dla tego kroku to "
  • Identyfikator klienta ('client_id') — appId wartość aplikacji uwierzytelnianej przez użytkownika końcowego w przepływie użytkownika. Nie jest to aplikacja appId zasobów w tokenach dostępu.
  • objectId — identyfikator użytkownika. Za pomocą tej funkcji można wykonywać zapytania dotyczące usług podrzędnych w celu uzyskania informacji o użytkowniku.

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 tym kroku oczekiwano typów odpowiedzi z internetowego interfejsu API

Gdy internetowy interfejs API odbiera żądanie HTTP z identyfikatora Entra firmy Microsoft podczas przepływu użytkownika, może zwrócić "odpowiedź kontynuacji".

Odpowiedź kontynuacji

Odpowiedź kontynuacji wskazuje, że przepływ użytkownika powinien przejść do następnego kroku: wystawiania tokenu. W odpowiedzi kontynuacji interfejs API może zwrócić dodatkowe oświadczenia. Oświadczenie zwrócone przez interfejs API, który ma zostać zwrócony w tokenie, musi być wbudowanym oświadczeniem lub zdefiniowanym jako atrybut niestandardowy i musi zostać wybrane w konfiguracji oświadczenia aplikacji przepływu użytkownika. Wartość oświadczenia w tokenie będzie zwracana przez interfejs API, a nie wartość 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.

Uwaga

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

Przykładowa odpowiedź

Przykład odpowiedzi kontynuacji

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 Type Wymagani opis
version String Tak Wersja interfejsu API.
action String Tak Wartość musi mieć wartość Continue.
<builtInUserAttribute> <typ-atrybutu> Nie. Można je zwrócić w tokenie, jeśli wybrano je jako oświadczenie aplikacji.
<extension_{extensions-app-id}_CustomAttribute> <typ-atrybutu> Nie. Oświadczenie nie musi zawierać _<extensions-app-id>_elementu , jest opcjonalne. Można je zwrócić w tokenie, jeśli wybrano je jako oświadczenie aplikacji.

W tym scenariuszu wzbogacamy dane tokenu użytkownika przez integrację z firmowym przepływem pracy. Podczas tworzenia konta lub logowania przy użyciu konta lokalnego lub federacyjnego usługa Azure AD B2C wywołuje interfejs API REST w celu uzyskania rozszerzonych danych profilu użytkownika ze zdalnego źródła danych. W tym przykładzie usługa Azure AD B2C wysyła unikatowy identyfikator użytkownika , objectId. Następnie interfejs API REST zwraca saldo konta użytkownika (liczbę losową). Użyj tego przykładu jako punktu wyjścia, aby zintegrować się z własnym systemem CRM, bazą danych marketingu lub dowolnym przepływem pracy biznesowym. Możesz również zaprojektować interakcję jako profil techniczny weryfikacji. Jest to odpowiednie, gdy interfejs API REST będzie weryfikował dane na ekranie i zwracał oświadczenia. Aby uzyskać więcej informacji, zobacz Przewodnik: dodawanie łącznika interfejsu API do przepływu użytkownika rejestracji.

Wymagania wstępne

Przygotowywanie punktu końcowego interfejsu API REST

W tym przewodniku należy mieć interfejs API REST, który sprawdza, czy identyfikator objectId usługi Azure AD B2C użytkownika jest zarejestrowany w systemie zaplecza. W przypadku zarejestrowania interfejs API REST zwraca saldo konta użytkownika. W przeciwnym razie interfejs API REST rejestruje nowe konto w katalogu i zwraca saldo 50.00początkowe . Poniższy kod JSON ilustruje dane, które usługa Azure AD B2C wyśle do punktu końcowego interfejsu API REST.

{
    "objectId": "User objectId",
    "lang": "Current UI language"
}

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

{
    "balance": "760.50"
}

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ń

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

  1. Otwórz plik rozszerzeń zasad. Na przykład SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
  2. Wyszukaj element BuildingBlocks. Jeśli element nie istnieje, dodaj go.
  3. Znajdź element ClaimsSchema . Jeśli element nie istnieje, dodaj go.
  4. Dodaj następujące oświadczenia do elementu ClaimsSchema .
<ClaimType Id="balance">
  <DisplayName>Your Balance</DisplayName>
  <DataType>string</DataType>
</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ółpracy z własną usługą RESTful. Usługa Azure AD B2C wysyła dane do usługi RESTful w InputClaims kolekcji i odbiera dane z powrotem w OutputClaims kolekcji. Znajdź element ClaimsProviders w pliku TrustFrameworkExtensions.xml i dodaj nowego dostawcę oświadczeń w następujący sposób:

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile 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/GetProfile?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="objectId" />
        <InputClaim ClaimTypeReferenceId="userLanguage" PartnerClaimType="lang" DefaultValue="{Culture:LCID}" AlwaysUseDefaultValue="true" />
      </InputClaims>
      <OutputClaims>
        <!-- Claims parsed from your REST API -->
        <OutputClaim ClaimTypeReferenceId="balance" />
      </OutputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

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

Konfigurowanie profilu technicznego interfejsu API RESTful

Po wdrożeniu interfejsu API REST ustaw metadane profilu technicznego REST-GetProfile , aby odzwierciedlały własny interfejs API REST, w tym:

  • ServiceUrl. Ustaw adres URL punktu końcowego interfejsu API REST.
  • SendClaimsIn. Określ sposób wysyłania oświadczeń wejściowych do dostawcy oświadczeń RESTful.
  • Typ uwierzytelniania. Ustawianie typu uwierzytelniania wykonywanego przez dostawcę oświadczeń RESTful, takiego jak Basic lub ClientCertificate
  • AllowInsecureAuthInProduction. W środowisku produkcyjnym upewnij się, że dla tych metadanych falseustawiono wartość .

Aby uzyskać więcej konfiguracji, zobacz metadane profilu technicznego RESTful. Powyższe AuthenticationType komentarze i AllowInsecureAuthInProduction określ zmiany, które należy wprowadzić podczas przechodzenia do środowiska produkcyjnego. Aby dowiedzieć się, jak zabezpieczyć interfejsy API RESTful dla środowiska produkcyjnego, zobacz Zabezpieczanie interfejsu API RESTful.

Dodawanie kroku aranżacji

Podróże użytkownika określają jawne ścieżki, za pośrednictwem których zasady umożliwiają aplikacji jednostki zależnej uzyskanie żądanych oświadczeń dla użytkownika. Podróż użytkownika jest reprezentowana jako sekwencja aranżacji, którą należy wykonać w celu pomyślnej transakcji. Kroki orkiestracji można dodawać lub odejmować. W takim przypadku dodasz nowy krok aranżacji, który służy do rozszerzania informacji dostarczonych do aplikacji po zarejestrowaniu się użytkownika lub zalogowaniu się za pośrednictwem wywołania interfejsu API REST.

  1. Otwórz plik podstawowy zasad. Na przykład SocialAndLocalAccounts/TrustFrameworkBase.xml.
  2. <UserJourneys> Wyszukaj element . Skopiuj cały element, a następnie usuń go.
  3. Otwórz plik rozszerzeń zasad. Na przykład SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
  4. Wklej element <UserJourneys> do pliku rozszerzeń po zamknięciu <ClaimsProviders> elementu.
  5. Znajdź element <UserJourney Id="SignUpOrSignIn">i dodaj następujący krok aranżacji przed ostatnim. 
    <OrchestrationStep Order="7" Type="ClaimsExchange">
  <ClaimsExchanges>
    <ClaimsExchange Id="RESTGetProfile" TechnicalProfileReferenceId="REST-GetProfile" />
  </ClaimsExchanges>
</OrchestrationStep>
  6. Refaktoryzuj ostatni krok aranżacji, zmieniając element na Order8. Ostatnie dwa kroki orkiestracji powinny wyglądać następująco: 
    <OrchestrationStep Order="7" Type="ClaimsExchange">
  <ClaimsExchanges>
    <ClaimsExchange Id="RESTGetProfile" TechnicalProfileReferenceId="REST-GetProfile" />
  </ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="8" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
  7. Powtórz dwa ostatnie kroki dla podróży użytkowników ProfileEdit i PasswordReset .

Dołączanie oświadczenia do tokenu

Aby zwrócić balance oświadczenie z powrotem do aplikacji jednostki uzależnionej, dodaj oświadczenie wyjściowe do SocialAndLocalAccounts/SignUpOrSignIn.xml pliku. Dodanie oświadczenia wyjściowego spowoduje wysłanie oświadczenia do tokenu po pomyślnej podróży użytkownika i zostanie wysłane do aplikacji. Zmodyfikuj element profilu technicznego w sekcji jednostki uzależnionej, aby dodać balance go 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="balance" DefaultValue="" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Powtórz ten krok dla podróży użytkownika ProfileEdit.xml i PasswordReset.xml . Zapisz zmienione pliki: TrustFrameworkBase.xml i TrustFrameworkExtensions.xml, SignUpOrSignin.xml, ProfileEdit.xml i PasswordReset.xml.

Testowanie zasad niestandardowych

  1. Zaloguj się w witrynie Azure Portal.
  2. Jeśli masz dostęp do wielu dzierżaw, wybierz ikonę Ustawienia w górnym menu, aby przełączyć się do dzierżawy usługi Azure AD B2C z menu Katalogi i subskrypcje.
  3. Wybierz pozycję Wszystkie usługi w lewym górnym rogu witryny Azure Portal, a następnie wyszukaj i wybierz pozycję Rejestracje aplikacji.
  4. Wybierz pozycję Identity Experience Framework(Struktura obsługi tożsamości).
  5. Wybierz pozycję Przekaż zasady niestandardowe, a następnie przekaż zmienione pliki zasad: TrustFrameworkBase.xml i TrustFrameworkExtensions.xml, SignUpOrSignin.xml, ProfileEdit.xml i PasswordReset.xml.
  6. Wybierz przekazane zasady rejestracji lub logowania, a następnie kliknij przycisk Uruchom teraz .
  7. Powinno być możliwe zarejestrowanie się przy użyciu adresu e-mail lub konta na Facebooku.
  8. Token wysłany z powrotem do aplikacji zawiera balance oświadczenie.
{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584961516,
  "nbf": 1584957916,
  "ver": "1.0",
  "iss": "https://contoso.b2clogin.com/f06c2fe8-709f-4030-85dc-38a4bfd9e82d/v2.0/",
  "aud": "e1d2612f-c2bc-4599-8e7b-d874eaca1ee1",
  "acr": "b2c_1a_signup_signin",
  "nonce": "defaultNonce",
  "iat": 1584957916,
  "auth_time": 1584957916,
  "name": "Emily Smith",
  "email": "emily@outlook.com",
  "given_name": "Emily",
  "family_name": "Smith",
  "balance": "202.75"
  ...
}

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ą tworzenie punktów końcowych interfejsu API do użycia z łącznikiem interfejsu API. Funkcja chmury bezserwerowej może również wywoływać i wywoływać inne internetowe interfejsy API, magazyny danych i inne usługi w chmurze w przypadku złożonych scenariuszy.

Najlepsze rozwiązania

Upewnij się, że:

  • Twój interfejs API śledzi kontrakty żądań interfejsu API i odpowiedzi zgodnie z powyższym opisem.
  • Adres URL punktu końcowego łącznika interfejsu API wskazuje prawidłowy punkt końcowy interfejsu API.
  • Interfejs API jawnie sprawdza wartości null odebranych oświadczeń, od których zależy.
  • Interfejs API implementuje metodę uwierzytelniania opisaną w temacie Zabezpieczanie łącznika interfejsu API.
  • Interfejs API reaguje tak szybko, jak to możliwe, aby zapewnić płynne środowisko użytkownika.
    • Usługa Azure AD B2C poczeka maksymalnie 20 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 używasz 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 pakietu szyfrowania usługi Azure AD B2C.

Korzystanie z rejestrowania

Korzystanie z funkcji chmury bezserwerowej

Funkcje bezserwerowe, takie jak wyzwalacze HTTP w usłudze Azure Functions, umożliwiają tworzenie punktów końcowych interfejsu API do użycia z łącznikiem interfejsu API. Funkcja chmury bezserwerowej może również wywoływać i wywoływać inne internetowe interfejsy API, magazyny danych i inne usługi w chmurze w przypadku złożonych scenariuszy.

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 interfejsu API.
  • W razie potrzeby użyj bardziej agresywnych poziomów rejestrowania (na przykład "ślad" lub "debuguj").
  • Monitoruj interfejs API pod kątem długich czasów odpowiedzi. Ponadto usługa Azure AD B2C rejestruje metadane dotyczące transakcji interfejsu API występujących podczas uwierzytelniania użytkowników za pośrednictwem przepływu użytkownika. Aby je znaleźć:
  1. Przejdź do usługi Azure AD B2C
  2. W obszarze Działania wybierz pozycję Dzienniki inspekcji.
  3. 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.
  4. 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. Wskazuje numberOfAttempts liczbę wywołań interfejsu API. Może to być 1wartość lub 2. Inne informacje o wywołaniu interfejsu API są szczegółowe w dziennikach. Screenshot of an example audit log with API connector transaction.

Następne kroki

Aby dowiedzieć się, jak zabezpieczyć interfejsy API, zobacz następujące artykuły: