Jak autoryzować konsolę testową portalu deweloperów, konfigurując autoryzację użytkownika protokołu OAuth 2.0
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
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:
Zarejestruj aplikację (aplikację zaplecza) w usłudze Microsoft Entra ID, aby reprezentować interfejs API.
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.
Skonfiguruj konsolę testową w portalu deweloperów, aby wywołać interfejs API przy użyciu autoryzacji użytkownika protokołu OAuth 2.0.
Skonfiguruj interfejs API do korzystania z autoryzacji użytkownika protokołu OAuth 2.0.
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:
Portal deweloperów żąda tokenu z identyfikatora Entra firmy Microsoft przy użyciu poświadczeń aplikacji klienckiej.
Po pomyślnej weryfikacji identyfikator Entra firmy Microsoft wystawia token dostępu/odświeżania.
Deweloper (użytkownik portalu deweloperów) wykonuje wywołanie interfejsu API z nagłówkiem autoryzacji.
Token jest weryfikowany przy użyciu
validate-jwt
zasad w usłudze API Management według identyfikatora Entra firmy Microsoft.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.
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
W witrynie Azure Portal wyszukaj i wybierz pozycję Rejestracje aplikacji.
Wybierz opcjęNowa rejestracja.
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.
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.
Wybierz pozycję Zarejestruj, aby utworzyć aplikację.
Na stronie Przegląd aplikacji znajdź wartość Identyfikator aplikacji (klienta) i zapisz ją później.
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.
Wybierz przycisk Dodaj zakres, aby wyświetlić stronę Dodawanie zakresu:
- Wprowadź nazwę zakresu dla zakresu obsługiwanego przez interfejs API (na przykład Files.Read).
- 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.
- Wprowadź nazwę wyświetlaną zgody administratora i opis zgody administratora.
- Upewnij się, że wybrano stan Włączone zakres.
Wybierz przycisk Dodaj zakres, aby utworzyć zakres.
Powtórz dwa poprzednie kroki, aby dodać wszystkie zakresy obsługiwane przez interfejs API.
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.
W witrynie Azure Portal wyszukaj i wybierz pozycję Rejestracje aplikacji.
Wybierz opcjęNowa rejestracja.
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.
W sekcji Identyfikator URI przekierowania wybierz pozycję Sieć Web i pozostaw pole adresu URL puste na razie.
Wybierz pozycję Zarejestruj, aby utworzyć aplikację.
Na stronie Przegląd aplikacji znajdź wartość Identyfikator aplikacji (klienta) i zapisz ją później.
Utwórz klucz tajny klienta dla tej aplikacji do użycia w kolejnym kroku.
- W sekcji Zarządzanie menu bocznego wybierz pozycję Certyfikaty i wpisy tajne.
- W obszarze Klucze tajne klienta wybierz pozycję + Nowy klucz tajny klienta.
- W obszarze Dodawanie wpisu tajnego klienta podaj opis i wybierz, kiedy klucz ma wygasnąć.
- 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.
W witrynie Azure Portal wyszukaj i wybierz pozycję Rejestracje aplikacji.
Wybierz aplikację kliencka. Następnie w menu bocznym wybierz pozycję Uprawnienia interfejsu API.
Wybierz pozycję + Dodaj uprawnienie.
W obszarze Wybierz interfejs API wybierz pozycję Moje interfejsy API, a następnie znajdź i wybierz aplikację zaplecza.
Wybierz pozycję Delegowane uprawnienia, a następnie wybierz odpowiednie uprawnienia do aplikacji zaplecza.
Wybierz Przyznaj uprawnienia.
Opcjonalnie:
Przejdź do strony uprawnień interfejsu API aplikacji klienckiej.
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
W witrynie Azure Portal przejdź do wystąpienia usługi API Management.
W obszarze Portal deweloperów w menu bocznym wybierz pozycję OAuth 2.0 + OpenID Connect.
Na karcie OAuth 2.0 wybierz pozycję + Dodaj.
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.
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
.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ś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ściaccessTokenAcceptedVersion
na2
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.
W obszarze Poświadczenia klienta wprowadź identyfikator klienta i klucz tajny klienta uzyskany podczas procesu tworzenia i konfigurowania aplikacji klienckiej.
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
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.
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.
Wybierz pozycję Utwórz , aby zapisać konfigurację serwera autoryzacji OAuth 2.0 usługi API Management.
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
- Konfigurowanie ustawień autoryzacji użytkownika protokołu OAuth 2.0 dla interfejsu API umożliwia usłudze API Management uzyskanie tokenu z serwera autoryzacji podczas korzystania z konsoli testowej w witrynie Azure Portal lub portalu dla deweloperów. Ustawienia serwera autoryzacji są również dodawane do definicji interfejsu API i dokumentacji.
- W przypadku autoryzacji OAuth 2.0 w czasie wykonywania aplikacja kliencka musi uzyskać i przedstawić token. Należy skonfigurować walidację tokenu w usłudze API Management lub interfejsie API zaplecza. Aby zapoznać się z przykładem, zobacz Protect an API in Azure API Management using OAuth 2.0 authorization with Microsoft Entra ID (Ochrona interfejsu API w usłudze Azure API Management przy użyciu autoryzacji OAuth 2.0 przy użyciu identyfikatora Entra firmy Microsoft).
Wybierz pozycję Interfejsy API z menu API Management po lewej stronie.
Wybierz nazwę żądanego interfejsu API i wybierz kartę Ustawienia . Przewiń do sekcji Zabezpieczenia , a następnie wybierz pozycję OAuth 2.0.
Wybierz żądany serwer autoryzacji z listy rozwijanej, a następnie wybierz pozycję Zapisz.
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.
Wybierz pozycję Portal dla deweloperów w górnym menu na stronie Przegląd wystąpienia usługi Azure API Management.
Przejdź do dowolnej operacji w obszarze interfejsu API w portalu dla deweloperów.
Wybierz pozycję Wypróbuj, aby przenieść Cię do konsoli dewelopera.
Zanotuj nowy element w sekcji Autoryzacja odpowiadający właśnie dodanemu serwerowi autoryzacji.
Wybierz pozycję Kod autoryzacji z listy rozwijanej autoryzacji.
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.
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
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.
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
URLaad-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ść
Aby uzyskać więcej informacji na temat używania protokołu OAuth 2.0 i usługi API Management, zobacz Protect a web API backend in Azure API Management using OAuth 2.0 authorization with Microsoft Entra ID (Ochrona zaplecza internetowego interfejsu API w usłudze Azure API Management przy użyciu autoryzacji OAuth 2.0 przy użyciu identyfikatora Entra firmy Microsoft).
Dowiedz się więcej o przepływie kodu autoryzacji Platforma tożsamości Microsoft i OAuth 2.0