Udostępnij za pośrednictwem

Jak autoryzować konsolę testową portalu deweloperów, konfigurując autoryzację użytkownika protokołu OAuth 2.0

  • Artykuł

DOTYCZY: Developer | Podstawowa | Podstawowa wersja 2 | Standardowa | Standardowa, wersja 2 | Premium | Premium, wersja 2

Wiele interfejsów API obsługuje protokół OAuth 2.0 w celu zabezpieczenia interfejsu API i zapewnia, że tylko prawidłowi użytkownicy mają dostęp i mogą uzyskiwać dostęp tylko do zasobów, do których mają prawo. Aby używać interaktywnej konsoli dewelopera usługi Azure API Management z takimi interfejsami API, usługa umożliwia skonfigurowanie zewnętrznego dostawcy na potrzeby autoryzacji użytkownika OAuth 2.0.

Skonfigurowanie autoryzacji użytkownika OAuth 2.0 w konsoli testowej portalu dla deweloperów zapewnia deweloperom wygodny sposób uzyskiwania tokenu dostępu OAuth 2.0. Z poziomu konsoli testowej token jest następnie przekazywany do zaplecza za pomocą wywołania interfejsu API. Walidacja tokenu musi być skonfigurowana oddzielnie — przy użyciu zasad weryfikacji JWT lub w usłudze zaplecza.

Wymagania wstępne

  • Wystąpienie usługi API Management.
  • Dostawca OAuth 2.0.

W tym artykule pokazano, jak skonfigurować wystąpienie usługi API Management do korzystania z autoryzacji OAuth 2.0 w konsoli testowej portalu deweloperów, ale nie pokazuje, jak skonfigurować dostawcę OAuth 2.0.

Jeśli jeszcze nie utworzono wystąpienia usługi API Management, zobacz Tworzenie wystąpienia usługi API Management.

Omówienie scenariusza

Skonfigurowanie autoryzacji użytkownika OAuth 2.0 w usłudze API Management umożliwia tylko konsolę testową portalu deweloperów (i konsolę testową w witrynie Azure Portal) jako klienta na uzyskanie tokenu z serwera autoryzacji. Konfiguracja każdego dostawcy protokołu OAuth 2.0 jest inna, chociaż kroki są podobne, a wymagane informacje używane do konfigurowania protokołu OAuth 2.0 w wystąpieniu usługi API Management są takie same. W tym artykule przedstawiono przykład użycia identyfikatora Entra firmy Microsoft jako dostawcy OAuth 2.0.

Poniżej przedstawiono kroki konfiguracji wysokiego poziomu:

  1. Zarejestruj aplikację (aplikację zaplecza) w usłudze Microsoft Entra ID, aby reprezentować interfejs API.

  2. Zarejestruj inną aplikację (client-app) w usłudze Microsoft Entra ID, aby reprezentować aplikację kliencką, która musi wywołać interfejs API — w tym przypadku konsola testowa portalu deweloperów.

    W usłudze Microsoft Entra ID udziel uprawnień, aby umożliwić aplikacji klienckiej wywołanie aplikacji zaplecza.

  3. Skonfiguruj konsolę testową w portalu deweloperów, aby wywołać interfejs API przy użyciu autoryzacji użytkownika protokołu OAuth 2.0.

  4. Skonfiguruj interfejs API do korzystania z autoryzacji użytkownika protokołu OAuth 2.0.

  5. Dodaj zasady, aby wstępnie autoryzować token protokołu OAuth 2.0 dla każdego żądania przychodzącego. Możesz użyć validate-jwt zasad dla dowolnego dostawcy OAuth 2.0.

Ta konfiguracja obsługuje następujący przepływ OAuth:

Grafika z omówieniem wizualnie koncepcyjna następującego przepływu.

  1. Portal deweloperów żąda tokenu z identyfikatora Entra firmy Microsoft przy użyciu poświadczeń aplikacji klienckiej.

  2. Po pomyślnej weryfikacji identyfikator Entra firmy Microsoft wystawia token dostępu/odświeżania.

  3. Deweloper (użytkownik portalu deweloperów) wykonuje wywołanie interfejsu API z nagłówkiem autoryzacji.

  4. Token jest weryfikowany przez dostawcę OAuth 2.0 przy użyciu validate-jwt zasad. W przypadku dostawcy identyfikatora Entra firmy Microsoft usługa API Management udostępnia validate-azure-ad-token również zasady.

  5. Na podstawie wyniku weryfikacji deweloper otrzyma odpowiedź w portalu deweloperów.

Typy udzielania autoryzacji

Usługa Azure API Management obsługuje następujące typy udzielania protokołu OAuth 2.0 (przepływy). Typ udzielania odnosi się do sposobu dla aplikacji klienckiej (w tym kontekście konsoli testowej w portalu deweloperów) w celu uzyskania tokenu dostępu do interfejsu API zaplecza. W zależności od dostawcy i scenariuszy protokołu OAuth 2.0 można skonfigurować co najmniej jeden typ dotacji.

Poniżej przedstawiono ogólne podsumowanie. Aby uzyskać więcej informacji na temat typów dotacji, zobacz typy udzielania autoryzacji OAuth 2.0 i OAuth.

Typ udzielenia opis Scenariusze
Kod autoryzacji Kod autoryzacji programu Exchanges dla tokenu Aplikacje po stronie serwera, takie jak aplikacje internetowe
Kod autoryzacji + PKCE Ulepszenie przepływu kodu autoryzacji, który tworzy wyzwanie kodu wysyłane przy użyciu żądania autoryzacji Klienci mobilni i publiczni, którzy nie mogą chronić wpisu tajnego lub tokenu
Niejawne (przestarzałe) Zwraca token dostępu natychmiast bez dodatkowego kroku wymiany kodu autoryzacji Klienci, którzy nie mogą chronić wpisu tajnego lub tokenu, takiego jak aplikacje mobilne i aplikacje jednostronicowe

Zazwyczaj nie jest to zalecane ze względu na ryzyko związane z zwróceniem tokenu dostępu w przekierowaniu HTTP bez potwierdzenia, że jest on odbierany przez klienta
Hasło właściciela zasobu Żąda poświadczeń użytkownika (nazwy użytkownika i hasła), zazwyczaj przy użyciu formularza interaktywnego Do użytku z wysoce zaufanymi aplikacjami

Należy używać tylko wtedy, gdy nie można używać innych, bezpieczniejszych przepływów
Poświadczenia klienta Uwierzytelnia i autoryzuje aplikację, a nie użytkownika Aplikacje maszynowo-maszynowe, które nie wymagają uprawnień określonego użytkownika do uzyskiwania dostępu do danych, takich jak interfejsy wiersza polecenia, demony lub usługi uruchomione na zapleczu

Zagadnienia dotyczące zabezpieczeń

Rozważ sposób generowania tokenu, zakresu tokenu i sposobu uwidocznienia tokenu. Naruszony token może być używany przez złośliwego aktora do uzyskiwania dostępu do dodatkowych zasobów w zakresie tokenu.

Podczas konfigurowania autoryzacji użytkownika OAuth 2.0 w konsoli testowej portalu deweloperów:

  • Ogranicz zakres tokenu do minimum potrzebnego deweloperom do testowania interfejsów API. Ogranicz zakres do konsoli testowej lub do interfejsów API, których dotyczy problem. Kroki konfigurowania zakresu tokenu zależą od dostawcy protokołu OAuth 2.0. Przykład pokazano w dalszej części tego artykułu przy użyciu identyfikatora Entra firmy Microsoft.

    W zależności od scenariuszy można skonfigurować bardziej lub mniej restrykcyjne zakresy tokenów dla innych aplikacji klienckich tworzonych w celu uzyskania dostępu do interfejsów API zaplecza.

  • Jeśli włączysz przepływ poświadczeń klienta, należy zachować szczególną ostrożność. Konsola testowa w portalu dla deweloperów, podczas pracy z przepływem poświadczeń klienta, nie o poświadczenia. Token dostępu może być przypadkowo uwidoczniony dla deweloperów lub anonimowych użytkowników konsoli dewelopera.

Śledzenie kluczowych informacji

W tym samouczku zostanie wyświetlony monit o zarejestrowanie kluczowych informacji w celu późniejszego odwołowania się do następujących elementów:

  • Identyfikator aplikacji zaplecza (klienta): identyfikator GUID aplikacji reprezentującej interfejs API zaplecza
  • Zakresy aplikacji zaplecza: co najmniej jeden zakres, który można utworzyć w celu uzyskania dostępu do interfejsu API. Format zakresu to api://<Backend Application (client) ID>/<Scope Name> (na przykład api://1764e900-1827-4a0b-9182-b2c1841864c2/Read)
  • Identyfikator aplikacji klienckiej (klienta): identyfikator GUID aplikacji reprezentującej portal dla deweloperów
  • Wartość wpisu tajnego aplikacji klienckiej: identyfikator GUID służący jako wpis tajny do interakcji z aplikacją kliencka w identyfikatorze Entra firmy Microsoft

Rejestrowanie aplikacji na serwerze OAuth

Musisz zarejestrować dwie aplikacje u dostawcy OAuth 2.0: jeden reprezentuje interfejs API zaplecza, który ma być chroniony, a drugi reprezentuje aplikację kliencką, która wywołuje interfejs API — w tym przypadku konsola testowa portalu deweloperów.

Poniżej przedstawiono przykładowe kroki użycia identyfikatora Entra firmy Microsoft jako dostawcy OAuth 2.0. Aby uzyskać szczegółowe informacje na temat rejestracji aplikacji, zobacz Szybki start: konfigurowanie aplikacji w celu uwidocznienia internetowego interfejsu API.

Rejestrowanie aplikacji w identyfikatorze Entra firmy Microsoft w celu reprezentowania interfejsu API

  1. W witrynie Azure Portal wyszukaj i wybierz pozycję Rejestracje aplikacji.

  2. Wybierz opcjęNowa rejestracja.

  3. Gdy pojawi się strona Rejestrowanie aplikacji, wprowadź informacje rejestracyjne aplikacji:

    • W sekcji Nazwa wprowadź zrozumiałą nazwę aplikacji, która będzie wyświetlana użytkownikom aplikacji, takiej jak backend-app.
    • W sekcji Obsługiwane typy kont wybierz opcję, która odpowiada Twojemu scenariuszowi.

  4. Pozostaw pustą sekcję Identyfikator URI przekierowania. Później dodasz identyfikator URI przekierowania wygenerowany w konfiguracji protokołu OAuth 2.0 w usłudze API Management.

  5. Wybierz pozycję Zarejestruj, aby utworzyć aplikację.

  6. Na stronie Przegląd aplikacji znajdź wartość Identyfikator aplikacji (klienta) i zapisz ją później.

  7. W sekcji Zarządzanie menu bocznego wybierz pozycję Uwidacznij interfejs API i ustaw identyfikator URI identyfikatora aplikacji z wartością domyślną. Zapisz tę wartość później.

  8. Wybierz przycisk Dodaj zakres, aby wyświetlić stronę Dodawanie zakresu:

    1. Wprowadź nazwę zakresu dla zakresu obsługiwanego przez interfejs API (na przykład Files.Read).
    2. W obszarze Kto może wyrazić zgodę?, wybierz swój scenariusz, taki jak Administratorzy i użytkownicy. Wybierz pozycję Administratorzy tylko w przypadku scenariuszy z wyższymi uprawnieniami.
    3. Wprowadź nazwę wyświetlaną zgody administratora i opis zgody administratora.
    4. Upewnij się, że wybrano stan Włączone zakres.

  9. Wybierz przycisk Dodaj zakres, aby utworzyć zakres.

  10. Powtórz dwa poprzednie kroki, aby dodać wszystkie zakresy obsługiwane przez interfejs API.

  11. Po utworzeniu zakresów zanotuj je do użycia w kolejnym kroku.

Rejestrowanie innej aplikacji w identyfikatorze Entra firmy Microsoft w celu reprezentowania aplikacji klienckiej

Zarejestruj każdą aplikację klienckę, która wywołuje interfejs API jako aplikację w identyfikatorze Entra firmy Microsoft.

  1. W witrynie Azure Portal wyszukaj i wybierz pozycję Rejestracje aplikacji.

  2. Wybierz opcjęNowa rejestracja.

  3. Gdy pojawi się strona Rejestrowanie aplikacji, wprowadź informacje rejestracyjne aplikacji:

    • W sekcji Nazwa wprowadź zrozumiałą nazwę aplikacji, która będzie wyświetlana użytkownikom aplikacji, na przykład client-app.
    • W sekcji Obsługiwane typy kont wybierz opcję, która odpowiada Twojemu scenariuszowi.

  4. W sekcji Identyfikator URI przekierowania wybierz pozycję Sieć Web i pozostaw pole adresu URL puste na razie.

  5. Wybierz pozycję Zarejestruj, aby utworzyć aplikację.

  6. Na stronie Przegląd aplikacji znajdź wartość Identyfikator aplikacji (klienta) i zapisz ją później.

  7. Utwórz klucz tajny klienta dla tej aplikacji do użycia w kolejnym kroku.

    1. W sekcji Zarządzanie menu bocznego wybierz pozycję Certyfikaty i wpisy tajne.
    2. W obszarze Klucze tajne klienta wybierz pozycję + Nowy klucz tajny klienta.
    3. W obszarze Dodawanie wpisu tajnego klienta podaj opis i wybierz, kiedy klucz ma wygasnąć.
    4. Wybierz Dodaj.

Po utworzeniu wpisu tajnego zanotuj wartość klucza do użycia w kolejnym kroku. Nie można ponownie uzyskać dostępu do wpisu tajnego w portalu.

Udzielanie uprawnień w identyfikatorze Entra firmy Microsoft

Po zarejestrowaniu dwóch aplikacji reprezentujących interfejs API i konsolę testową przyznaj uprawnienia, aby umożliwić aplikacji klienckiej wywołanie aplikacji zaplecza.

  1. W witrynie Azure Portal wyszukaj i wybierz pozycję Rejestracje aplikacji.

  2. Wybierz aplikację klienta. Następnie w menu bocznym wybierz pozycję Uprawnienia interfejsu API.

  3. Wybierz + Dodaj uprawnienie.

  4. W obszarze Wybierz interfejs API wybierz pozycję Moje interfejsy API, a następnie znajdź i wybierz aplikację zaplecza (rejestrację aplikacji dla interfejsu API zaplecza).

  5. Wybierz pozycję Delegowane uprawnienia, a następnie wybierz odpowiednie uprawnienia do aplikacji zaplecza.

  6. Wybierz Przyznaj uprawnienia.

Opcjonalnie:

  1. Przejdź do strony uprawnień interfejsu API aplikacji klienckiej.

  2. Wybierz pozycję Udziel zgody administratora dla <nazwy> dzierżawy, aby udzielić zgody w imieniu wszystkich użytkowników w tym katalogu.

Konfigurowanie serwera autoryzacji OAuth 2.0 w usłudze API Management

  1. W witrynie Azure Portal przejdź do wystąpienia usługi API Management.

  2. W obszarze Portal deweloperów w menu bocznym wybierz pozycję OAuth 2.0 + OpenID Connect.

  3. Na karcie OAuth 2.0 wybierz pozycję + Dodaj.

    Menu OAuth 2.0

  4. Wprowadź nazwę i opcjonalny opis w polach Nazwa i Opis .

    Uwaga

    Te pola identyfikują serwer autoryzacji OAuth 2.0 w bieżącej usłudze API Management. Ich wartości nie pochodzą z serwera OAuth 2.0.

  5. Wprowadź adres URL strony rejestracji klienta — na przykład https://contoso.com/login. Ta strona umożliwia użytkownikom tworzenie kont i zarządzanie nimi, jeśli dostawca OAuth 2.0 obsługuje zarządzanie kontami użytkowników. Strona różni się w zależności od używanego dostawcy OAuth 2.0.

    Jeśli dostawca OAuth 2.0 nie ma skonfigurowanego zarządzania użytkownikami kont, wprowadź tutaj adres URL symbolu zastępczego, taki jak adres URL firmy lub adres URL, taki jak http://localhost.

    Nowy serwer OAuth 2.0

  6. W następnej sekcji formularza znajdują się typy udzielania autoryzacji, adres URL punktu końcowego autoryzacji i ustawienia metody żądania autoryzacji.

    • Wybierz co najmniej jeden żądany typ udzielania autoryzacji. W tym przykładzie wybierz pozycję Kod autoryzacji (wartość domyślna). Dowiedz się więcej

    • Wprowadź adres URL punktu końcowego autoryzacji. Adres URL punktu końcowego można uzyskać na stronie Punkty końcowe jednej z rejestracji aplikacji. W przypadku aplikacji z jedną dzierżawą w identyfikatorze Entra firmy Microsoft ten adres URL będzie podobny do jednego z następujących adresów URL, gdzie {aad-tenant} jest zastępowany identyfikatorem dzierżawy firmy Microsoft Entra.

      Zaleca się korzystanie z punktu końcowego w wersji 2; usługa API Management obsługuje jednak punkty końcowe w wersji 1 i 2.

      https://login.microsoftonline.com/{aad-tenant}/oauth2/v2.0/authorize (wersja 2)

      https://login.microsoftonline.com/{aad-tenant}/oauth2/authorize (wersja 1)

    • Metoda żądania autoryzacji określa sposób wysyłania żądania autoryzacji do serwera OAuth 2.0. Wybierz pozycję POST.

    Określanie ustawień autoryzacji

  7. Określ adres URL punktu końcowego tokenu, metody uwierzytelniania klienta, metodę wysyłania tokenu dostępu i zakres domyślny.

    • Wprowadź adres URL punktu końcowego tokenu. W przypadku pojedynczej aplikacji dzierżawy w identyfikatorze Entra firmy Microsoft będzie ona podobna do jednego z następujących adresów URL, gdzie {aad-tenant} jest zastępowana identyfikatorem dzierżawy firmy Microsoft Entra. Użyj tej samej wersji punktu końcowego (wersja 2 lub v1), która jest wcześniej wybrana.

      https://login.microsoftonline.com/{aad-tenant}/oauth2/v2.0/token (wersja 2)

      https://login.microsoftonline.com/{aad-tenant}/oauth2/token (wersja 1)

    • Jeśli używasz punktów końcowych w wersji 1 , dodaj parametr treści:
      * Nazwa: zasób.
      * Wartość: identyfikator aplikacji zaplecza (klienta).

    • Jeśli używasz punktów końcowych w wersji 2 :
      * Wprowadź zakres aplikacji zaplecza utworzony w polu Zakres domyślny.
      * Ustaw wartość właściwości accessTokenAcceptedVersion na 2 w manifeście aplikacji zarówno dla aplikacji zaplecza, jak i rejestracji aplikacji klienckiej.

    • Zaakceptuj ustawienia domyślne metod uwierzytelniania klienta i metody wysyłania tokenu dostępu.

  8. W obszarze Poświadczenia klienta wprowadź identyfikator klienta i klucz tajny klienta uzyskany podczas procesu tworzenia i konfigurowania aplikacji klienckiej.

  9. Po określeniu identyfikatora klienta i klucza tajnego klienta zostanie wygenerowany identyfikator URI przekierowania dla kodu autoryzacji. Ten identyfikator URI służy do konfigurowania identyfikatora URI przekierowania w konfiguracji serwera OAuth 2.0.

    W portalu dla deweloperów sufiks identyfikatora URI ma postać:

    • /signin-oauth/code/callback/{authServerName} dla przepływu udzielania kodu autoryzacji
    • /signin-oauth/implicit/callback dla przepływu niejawnego udzielania

    Dodawanie poświadczeń klienta dla usługi OAuth 2.0

    Skopiuj odpowiedni identyfikator URI przekierowania na stronę Uwierzytelnianie rejestracji aplikacji klienckiej. W rejestracji aplikacji wybierz pozycję Uwierzytelnianie>+ Dodaj sieć Web platformy>, a następnie wprowadź identyfikator URI przekierowania.

  10. Jeśli typy udzielania autoryzacji są ustawione na hasło właściciela zasobu, sekcja Poświadczenia hasła właściciela zasobu jest używana do określania tych poświadczeń. W przeciwnym razie możesz pozostawić je puste.

  11. Wybierz pozycję Utwórz , aby zapisać konfigurację serwera autoryzacji OAuth 2.0 usługi API Management.

  12. Opublikuj ponownie portal deweloperów.

    Ważne

    Podczas wprowadzania zmian związanych z protokołem OAuth 2.0 należy ponownie opublikować portal deweloperów po każdej modyfikacji w miarę istotnych zmian (na przykład zmiany zakresu) w przeciwnym razie nie można propagować do portalu, a następnie używać ich podczas wypróbowywanie interfejsów API.

Konfigurowanie interfejsu API do korzystania z autoryzacji użytkownika OAuth 2.0

Po zapisaniu konfiguracji serwera OAuth 2.0 skonfiguruj interfejs API lub interfejsy API do korzystania z tej konfiguracji.

Ważne

  1. Wybierz pozycję Interfejsy API z menu API Management po lewej stronie.

  2. Wybierz nazwę żądanego interfejsu API i wybierz kartę Ustawienia . Przewiń do sekcji Zabezpieczenia , a następnie wybierz pozycję OAuth 2.0.

  3. Wybierz żądany serwer autoryzacji z listy rozwijanej, a następnie wybierz pozycję Zapisz.

    Konfigurowanie serwera autoryzacji OAuth 2.0

Portal dla deweloperów — testowanie autoryzacji użytkownika OAuth 2.0

Po skonfigurowaniu serwera autoryzacji OAuth 2.0 i skonfigurowaniu interfejsu API do korzystania z tego serwera można go przetestować, przechodząc do portalu deweloperów i wywołując interfejs API.

  1. Wybierz pozycję Portal dla deweloperów w górnym menu na stronie Przegląd wystąpienia usługi Azure API Management.

  2. Przejdź do dowolnej operacji w obszarze interfejsu API w portalu dla deweloperów.

  3. Wybierz pozycję Wypróbuj, aby przenieść Cię do konsoli dewelopera.

  4. Zanotuj nowy element w sekcji Autoryzacja odpowiadający właśnie dodanemu serwerowi autoryzacji.

  5. Wybierz pozycję Kod autoryzacji z listy rozwijanej autoryzacji.

    Wybierz pozycję Autoryzacja kodu autoryzacji

  6. Po wyświetleniu monitu zaloguj się do dzierżawy microsoft Entra.

    • Jeśli konto zostało już zalogowane, może nie zostać wyświetlony monit.

  7. Po pomyślnym zalogowaniu Authorization do żądania zostanie dodany nagłówek z tokenem dostępu z identyfikatora Entra firmy Microsoft. Poniżej przedstawiono skrócony przykładowy token (zakodowany w formacie Base64):

    Authorization: Bearer eyJ0eXAiOi[...]3pkCfvEOyA

  8. Skonfiguruj żądane wartości dla pozostałych parametrów i wybierz pozycję Wyślij , aby wywołać interfejs API.

Konfigurowanie zasad weryfikacji JWT w celu wstępnego autoryzowania żądań

W konfiguracji do tej pory usługa API Management nie weryfikuje tokenu dostępu. Przekazuje token tylko w nagłówku autoryzacji do interfejsu API zaplecza.

Aby wstępnie autoryzować żądania, skonfiguruj zasady validate-jwt w celu zweryfikowania tokenu dostępu każdego żądania przychodzącego. Jeśli żądanie nie ma prawidłowego tokenu, usługa API Management blokuje je. Korzystając z dostawcy identyfikatora Entra firmy Microsoft, możesz również użyć zasad validate-azure-ad-token .

Poniższe przykładowe zasady po dodaniu do <inbound> sekcji zasad sprawdzają wartość oświadczenia odbiorców w tokenie dostępu uzyskanym z identyfikatora Entra firmy Microsoft przedstawionego w nagłówku Autoryzacja. Zwraca komunikat o błędzie, jeśli token jest nieprawidłowy. Skonfiguruj te zasady w zakresie zasad, który jest odpowiedni dla danego scenariusza.

  • W adresie openid-config URL aad-tenant jest to identyfikator dzierżawy w identyfikatorze Entra firmy Microsoft. Znajdź tę wartość w witrynie Azure Portal, na przykład na stronie Przegląd zasobu Microsoft Entra. W przedstawionym przykładzie przyjęto założenie, że aplikacja Firmy Microsoft Entra z jedną dzierżawą i punkt końcowy konfiguracji w wersji 2.
  • Wartość parametru claim to identyfikator klienta aplikacji zaplecza zarejestrowanej w identyfikatorze Entra firmy Microsoft.
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
    <openid-config url="https://login.microsoftonline.com/{aad-tenant}/v2.0/.well-known/openid-configuration" />
    <audiences>
        <audience>{audience-value - (ex:api://guid)}</audience>
    </audiences>
    <issuers>
        <issuer>{issuer-value - (ex: https://sts.windows.net/{tenant id}/)}</issuer>
    </issuers>
    <required-claims>
        <claim name="aud">
            <value>{backend-app-client-id}</value>
        </claim>
    </required-claims>
</validate-jwt>

Uwaga

Powyższy openid-config adres URL odpowiada punktowi końcowemu w wersji 2. W przypadku punktu końcowego w wersji 1 openid-config użyj polecenia https://login.microsoftonline.com/{aad-tenant}/.well-known/openid-configuration.

Aby uzyskać informacje na temat konfigurowania zasad, zobacz Ustawianie lub edytowanie zasad. Zapoznaj się z dokumentacją validate-jwt , aby uzyskać więcej informacji na temat dostosowywania weryfikacji JWT. Aby zweryfikować JWT, który został dostarczony przez usługę Microsoft Entra, usługa API Management udostępnia validate-azure-ad-token również zasady.

Powiązana zawartość