A fejlesztői portál tesztkonzoljának engedélyezése az OAuth 2.0 felhasználói engedélyezésének konfigurálásával

A KÖVETKEZŐKRE VONATKOZIK: Fejlesztő | Alapszintű | Alapszintű v2 | Standard | Standard v2 | Prémium

Számos API támogatja az OAuth 2.0-t az API védelméhez és annak biztosításához, hogy csak érvényes felhasználók férhessenek hozzá, és csak azokhoz az erőforrásokhoz férhessenek hozzá, amelyekre jogosultak. Az Azure API Management interaktív fejlesztői konzoljának ilyen API-kkal való használatához a szolgáltatás lehetővé teszi egy külső szolgáltató konfigurálását az OAuth 2.0 felhasználói engedélyezéséhez.

Az OAuth 2.0 felhasználói engedélyezésének konfigurálása a fejlesztői portál tesztkonzolján lehetővé teszi a fejlesztők számára az OAuth 2.0 hozzáférési jogkivonat beszerzésének kényelmes módját. A tesztkonzolon a jogkivonatot az API-hívással továbbítja a háttérrendszernek. A jogkivonat-érvényesítést külön kell konfigurálni – JWT érvényesítési szabályzat használatával vagy a háttérszolgáltatásban.

Előfeltételek

Ez a cikk bemutatja, hogyan konfigurálhatja az API Management szolgáltatáspéldányt OAuth 2.0-hitelesítés használatára a fejlesztői portál tesztkonzolján, de nem mutatja be, hogyan konfigurálhat OAuth 2.0-szolgáltatót.

Ha még nem hozott létre API Management szolgáltatáspéldányt, olvassa el az API Management szolgáltatáspéldány létrehozása című témakört.

Forgatókönyv áttekintése

Az OAuth 2.0 felhasználói hitelesítés API Managementben való konfigurálásával csak a fejlesztői portál tesztkonzolja (és az Azure Portal tesztkonzolja) szerezhet be jogkivonatot az engedélyezési kiszolgálóról. Az egyes OAuth 2.0-szolgáltatók konfigurációja eltérő, bár a lépések hasonlóak, és az OAuth 2.0 API Management-szolgáltatáspéldányban való konfigurálásához szükséges információk megegyeznek. Ez a cikk egy példát mutat be, amely a Microsoft Entra ID-t használja OAuth 2.0-szolgáltatóként.

A magas szintű konfiguráció lépései a következők:

1. Regisztráljon egy alkalmazást (backend-app) a Microsoft Entra ID-ben az API megjelenítésére.

2. Regisztráljon egy másik alkalmazást (ügyfélalkalmazást) a Microsoft Entra-azonosítóban, hogy egy olyan ügyfélalkalmazást jelöljön, amely meghívja az API-t – ebben az esetben a fejlesztői portál tesztkonzolját.

   A Microsoft Entra ID-ban adjon engedélyeket, hogy az ügyfél-alkalmazás hívhassa a háttértár-alkalmazást.

3. Konfigurálja a tesztkonzolt a fejlesztői portálon úgy, hogy meghívjon egy API-t az OAuth 2.0 felhasználói engedélyezésének használatára.

4. Konfiguráljon egy API-t az OAuth 2.0 felhasználói hitelesítés használatára.

5. Adjon hozzá egy szabályzatot az OAuth 2.0-jogkivonat előzetes engedélyezéséhez minden bejövő kéréshez. A szabályzatot validate-jwt bármely OAuth 2.0-szolgáltatóhoz használhatja.

Ez a konfiguráció a következő OAuth-folyamatot támogatja:

1. A fejlesztői portál jogkivonatot kér a Microsoft Entra-azonosítótól az ügyfélalkalmazás hitelesítő adataival.

2. A sikeres érvényesítés után a Microsoft Entra ID kiadja a hozzáférési/frissítési jogkivonatot.

3. A fejlesztő (a fejlesztői portál felhasználója) api-hívást kezdeményez az engedélyezési fejléccel.

4. A jogkivonat érvényesítése a validate-jwt Microsoft Entra ID API Management-szabályzatával történik.

5. Az érvényesítési eredmény alapján a fejlesztő megkapja a választ a fejlesztői portálon.

Engedélyezési engedélyezési típusok

Az Azure API Management a következő OAuth 2.0-s támogatási típusokat (folyamatokat) támogatja. A támogatási típus egy ügyfélalkalmazás (ebben a kontextusban a fejlesztői portál tesztkonzolja) egy hozzáférési jogkivonat beszerzésének módját jelenti a háttér API-hoz. Az OAuth 2.0 szolgáltatójától és forgatókönyveitől függően konfigurálhat egy vagy több támogatási típust.

A következő egy magas szintű összefoglalás. A támogatástípusokról további információt az OAuth 2.0 engedélyezési keretrendszerében és az OAuth-támogatástípusokban talál.

Megadás típusa	Leírás	Forgatókönyvek
Engedélyezési kód	Exchanges engedélyezési kód jogkivonathoz	Kiszolgálóoldali alkalmazások, például webalkalmazások
Engedélyezési kód + PKCE	Az engedélyezési kódfolyamat fejlesztése, amely egy engedélyezési kéréssel küldött kódkérdést hoz létre	Olyan mobil- és nyilvános ügyfelek, amelyek nem képesek titkos kódok vagy jogkivonatok védelmére
Implicit (elavult)	Azonnal visszaadja a hozzáférési jogkivonatot további engedélyezési kódcsere-lépés nélkül	Olyan ügyfelek, amelyek nem tudnak titkos kódokat vagy jogkivonatokat védeni, például mobilalkalmazásokat és egyoldalas alkalmazásokat Általában nem ajánlott, mert a hozzáférési jogkivonat HTTP-átirányításban való visszaadásának kockázatai nem igazolják, hogy az ügyfél megkapta
Erőforrás-tulajdonos jelszava	Felhasználói hitelesítő adatokat (felhasználónevet és jelszót) kér, általában interaktív űrlap használatával	Magas megbízhatóságú alkalmazásokhoz Csak akkor szabad használni, ha más, biztonságosabb folyamatok nem használhatók
Ügyfél-hitelesítő adatok	Felhasználó helyett egy alkalmazás hitelesítése és engedélyezése	Olyan gépről gépre irányuló alkalmazások, amelyekhez nem szükséges egy adott felhasználó engedélye az adatokhoz való hozzáféréshez, például CLI-khez, démonokhoz vagy a háttérrendszeren futó szolgáltatásokhoz

Biztonsági szempontok

Fontolja meg, hogy a megadás típusa hogyan hoz létre jogkivonatot, a jogkivonat hatókörét és a jogkivonat felfedésének módját. A rosszindulatú szereplők feltört jogkivonatot használhatnak a jogkivonat hatókörén belüli további erőforrások eléréséhez.

Az OAuth 2.0 felhasználói engedélyezésének konfigurálásakor a fejlesztői portál tesztkonzolján:

• A jogkivonat hatókörének korlátozása a fejlesztők számára az API-k teszteléséhez szükséges minimálisra . Korlátozza a hatókört a tesztkonzolra vagy az érintett API-kra. A jogkivonat hatókörének konfigurálásához szükséges lépések az OAuth 2.0-szolgáltatótól függenek.

  A forgatókönyvtől függően több vagy kevésbé korlátozó jogkivonat-hatókört is konfigurálhat a háttérbeli API-k eléréséhez létrehozott más ügyfélalkalmazásokhoz.

• Ha engedélyezi az ügyfél hitelesítő adatainak folyamatát, fokozottan ügyeljen rá. A fejlesztői portál tesztkonzolja az ügyfél-hitelesítő adatok folyamatának használatakor nem kér hitelesítő adatokat. A hozzáférési jogkivonatok véletlenül közzétehetők a fejlesztői konzol fejlesztői vagy névtelen felhasználói számára.

A kulcsadatok nyomon követése

Ebben az oktatóanyagban a rendszer kérni fogja, hogy rögzítse a kulcsinformációkat, hogy később hivatkozzon rájuk:

• Háttéralkalmazás (ügyfél) azonosítója: A háttér API-t képviselő alkalmazás GUID azonosítója
• Háttéralkalmazás-hatókörök: Az API eléréséhez létrehozhat egy vagy több hatókört. A hatókör formátuma api://<Backend Application (client) ID>/<Scope Name> (például api://1764e900-1827-4a0b-9182-b2c1841864c2/Read)
• Ügyfélalkalmazás (ügyfél) azonosítója: A fejlesztői portált képviselő alkalmazás GUID azonosítója
• Ügyfélalkalmazás titkos azonosítója: Az ügyfélalkalmazással való interakció titkos kódjaként szolgáló GUID a Microsoft Entra-azonosítóban

Alkalmazások regisztrálása az OAuth-kiszolgálóval

Két alkalmazást kell regisztrálnia az OAuth 2.0 szolgáltatónál: az egyik a védendő háttér API-t, a második pedig az API-t meghívó ügyfélalkalmazást jelöli – ebben az esetben a fejlesztői portál tesztkonzolját.

Az alábbi példalépések a Microsoft Entra ID-t OAuth 2.0-szolgáltatóként használják. Az alkalmazásregisztrációval kapcsolatos részletekért tekintse meg a rövid útmutatót: Alkalmazás konfigurálása webes API-k megjelenítéséhez.

Alkalmazás regisztrálása a Microsoft Entra-azonosítóban az API-t ábrázoló módon

1. Az Azure Portalon keresse meg és válassza ki a Alkalmazásregisztrációk.

2. Új regisztráció kiválasztása.

3. Amikor megjelenik az Alkalmazás regisztrálása lap, adja meg az alkalmazás regisztrációs adatait:

   • A Név szakaszban adjon meg egy értelmes alkalmazásnevet, amely megjelenik az alkalmazás felhasználóinak, például a háttéralkalmazásnak.
   • A Támogatott fióktípusok szakaszban válasszon egy, a forgatókönyvnek megfelelő lehetőséget.

4. Hagyja üresen az Átirányítás URI szakaszt. Később hozzáad egy átirányítási URI-t, amely az API Management OAuth 2.0-konfigurációjában jön létre.

5. Válassza a Regisztráció elemet az alkalmazás létrehozásához.

6. Az Alkalmazás áttekintése lapon keresse meg az alkalmazás (ügyfél) azonosítójának értékét, és jegyezze fel későbbre.

7. Az oldalmenü Kezelés szakaszában válassza az API-k felfedése lehetőséget, és állítsa be az alkalmazásazonosító URI-ját az alapértelmezett értékkel. Jegyezze fel ezt az értéket későbbre.

8. A Hatókör hozzáadása lap megjelenítéséhez válassza a Hatókör hozzáadása gombot:

   1. Adja meg az API által támogatott hatókör (például Files.Read) hatókörnevét.
   2. A Ki tud hozzájárulni? területen válasszon a forgatókönyvhöz, például a Rendszergazda és a felhasználók számára. Csak magasabb jogosultsági szintű forgatókönyvekhez válassza ki a Rendszergazda.
   3. Adja meg Rendszergazda hozzájárulás megjelenítendő nevét és Rendszergazda hozzájárulás leírását.
   4. Győződjön meg arról, hogy az Engedélyezett hatókör állapota ki van jelölve.

9. A hatókör létrehozásához válassza a Hatókör hozzáadása gombot.

10. Ismételje meg az előző két lépést az API által támogatott összes hatókör hozzáadásához.

11. A hatókörök létrehozása után jegyezze fel őket egy későbbi lépésben való használatra.

Másik alkalmazás regisztrálása a Microsoft Entra-azonosítóban egy ügyfélalkalmazás megjelenítéséhez

Regisztráljon minden olyan ügyfélalkalmazást, amely alkalmazásként meghívja az API-t a Microsoft Entra ID-ban.

1. Az Azure Portalon keresse meg és válassza ki a Alkalmazásregisztrációk.

2. Új regisztráció kiválasztása.

3. Amikor megjelenik az Alkalmazás regisztrálása lap, adja meg az alkalmazás regisztrációs adatait:

   • A Név szakaszban adjon meg egy értelmes alkalmazásnevet, amely megjelenik az alkalmazás felhasználóinak, például az ügyfélalkalmazásnak.
   • A Támogatott fióktípusok szakaszban válasszon egy, a forgatókönyvnek megfelelő lehetőséget.

4. Az Átirányítási URI szakaszban válassza a Web lehetőséget, és hagyja üresen az URL-mezőt.

5. Válassza a Regisztráció elemet az alkalmazás létrehozásához.

6. Az Alkalmazás áttekintése lapon keresse meg az alkalmazás (ügyfél) azonosítójának értékét, és jegyezze fel későbbre.

7. Hozzon létre egy ügyfélkulcsot az alkalmazáshoz, amelyet egy későbbi lépésben használhat.

   1. Az oldalmenü Kezelés szakaszában válassza a Tanúsítványok > titkos kódok lehetőséget.
   2. Az Ügyfélkódok területen válassza az + Új ügyfélkód lehetőséget.
   3. Az Ügyfélkód hozzáadása csoportban adja meg a leírást, és adja meg, hogy mikor járjon le a kulcs.
   4. Válassza a Hozzáadás lehetőséget.

A titkos kód létrehozásakor jegyezze fel a kulcs értékét egy későbbi lépésben. A titkos kód nem érhető el újra a portálon.

Engedélyek megadása a Microsoft Entra-azonosítóban

Most, hogy regisztrált két alkalmazást, amelyek az API-t és a tesztkonzolt jelölik, adjon meg engedélyeket, hogy az ügyfélalkalmazás meghívhassa a háttéralkalmazást.

1. Az Azure Portalon keresse meg és válassza ki a Alkalmazásregisztrációk.

2. Válassza ki az ügyfélalkalmazást. Ezután az oldalsó menüben válassza az API-engedélyeket.

3. Válassza a + Engedély hozzáadása lehetőséget.

4. Az API kiválasztása területen válassza a Saját API-k lehetőséget, majd keresse meg és válassza ki a háttéralkalmazást.

5. Válassza a Delegált engedélyek lehetőséget, majd válassza ki a háttéralkalmazás megfelelő engedélyeit.

6. Jelölje be az Engedélyek hozzáadása lehetőséget.

Vagy:

1. Lépjen az ügyfélalkalmazás API-engedélyeinek lapjára.

2. Válassza a rendszergazdai hozzájárulás megadását a bérlői névhez <> a címtárban lévő összes felhasználó nevében történő hozzájárulás megadásához.

OAuth 2.0 engedélyezési kiszolgáló konfigurálása az API Managementben

1. Az Azure Portalon keresse meg az API Management-példányt.

2. Az oldalmenü Fejlesztői portál területén válassza az OAuth 2.0 + OpenID Csatlakozás lehetőséget.

3. Az OAuth 2.0 lapon válassza a + Hozzáadás lehetőséget.

   

4. Adjon meg egy nevet és egy opcionális leírást a Név és leírás mezőkben.

   Feljegyzés

   Ezek a mezők azonosítják az OAuth 2.0 engedélyezési kiszolgálót az aktuális API Management szolgáltatásban. Az értékek nem az OAuth 2.0-kiszolgálóról származnak.

5. Adja meg az ügyfélregisztrációs oldal URL-címét – például https://contoso.com/login. Ezen a lapon hozhatják létre és kezelhetik a fiókjukat, ha az OAuth 2.0 szolgáltató támogatja a fiókok felhasználói kezelését. A lap a használt OAuth 2.0 szolgáltatótól függően változik.

   Ha az OAuth 2.0-szolgáltató nem rendelkezik a fiókok felhasználói felügyeletével, itt adjon meg egy helyőrző URL-címet, például a vállalat URL-címét, vagy egy URL-címet, például http://localhost.

   

6. Az űrlap következő szakasza tartalmazza az engedélyezés megadásának típusait, az engedélyezési végpont URL-címét és az engedélyezési kérelem metódusának beállításait.

   • Válasszon ki egy vagy több kívánt engedélyezési engedélyezési típust. Ebben a példában válassza az Engedélyezési kódot (az alapértelmezett). További információ

   • Adja meg az engedélyezési végpont URL-címét. A végpont URL-címét az egyik alkalmazásregisztráció Végpontok lapján szerezheti be. A Microsoft Entra ID-ban található egybérlős alkalmazások esetében ez az URL-cím az alábbi URL-címek egyikéhez hasonló lesz, ahol {aad-tenant} a Rendszer lecseréli a Microsoft Entra-bérlő azonosítójára.

     A v2-végpont használata ajánlott; Az API Management azonban támogatja az 1-es és a 2-es verziójú végpontokat is.

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

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

   • Az engedélyezési kérelem metódusa határozza meg, hogy a rendszer hogyan küldi el az engedélyezési kérelmet az OAuth 2.0-kiszolgálónak. Válassza a POST lehetőséget.

   

7. Adja meg a tokenvégpont URL-címét, az ügyfél-hitelesítési módszereket, az Access-jogkivonat-küldési módszert és az alapértelmezett hatókört.

   • Adja meg a jogkivonat végpontjának URL-címét. A Microsoft Entra-azonosítóban lévő egyetlen bérlői alkalmazás esetében az alábbi URL-címek egyikéhez hasonló lesz, ahol {aad-tenant} a Rendszer lecseréli a Microsoft Entra-bérlő azonosítójára. Használja ugyanazt a végpontverziót (v2 vagy v1), amelyet korábban választott.

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

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

   • V1-végpontok használata esetén adjon hozzá egy törzsparamétert:
     * Név: erőforrás.
     * Érték: a háttéralkalmazás (ügyfél) azonosítója.

   • V2-végpontok használata esetén:
     * Adja meg az Alapértelmezett hatókör mezőben létrehozott háttéralkalmazás-hatókört .
     * Állítsa be a tulajdonság 2 értékét az accessTokenAcceptedVersion alkalmazásjegyzékben mind a háttéralkalmazás, mind az ügyfélalkalmazás-regisztrációk esetében.

   • Fogadja el az ügyfél-hitelesítési módszerek és az Access-jogkivonat-küldési módszer alapértelmezett beállításait.

8. Az ügyfél hitelesítő adatai között adja meg az ügyfélalkalmazás létrehozási és konfigurációs folyamata során beszerzett ügyfél-azonosítót és ügyfélkulcsot.

9. Az ügyfélazonosító és az ügyfél titkos kódjának megadása után létre lesz hozva az engedélyezési kód átirányítási URI-ja. Ez az URI az átirányítási URI konfigurálására szolgál az OAuth 2.0-kiszolgáló konfigurációjában.

   A fejlesztői portálon az URI utótag az alábbi formában érhető el:

   • /signin-oauth/code/callback/{authServerName} engedélyezési kód engedélyezési folyamatához
   • /signin-oauth/implicit/callback implicit engedélyezési folyamat esetén

   

   Másolja a megfelelő átirányítási URI-t az ügyfélalkalmazás-regisztráció hitelesítési oldalára. Az alkalmazásregisztrációban válassza a Hitelesítés>+ Platformweb> hozzáadása lehetőséget, majd adja meg az átirányítási URI-t.

10. Ha az engedélyezési engedélyezési típusok erőforrás-tulajdonosi jelszóra vannak beállítva, az erőforrás-tulajdonos jelszó hitelesítő adatai szakasza adja meg ezeket a hitelesítő adatokat, ellenkező esetben üresen hagyhatja.

11. Válassza a Létrehozás lehetőséget az API Management OAuth 2.0 engedélyezési kiszolgáló konfigurációjának mentéséhez.

12. Tegye közzé újra a fejlesztői portált.

    Fontos

    Az OAuth 2.0-hoz kapcsolódó módosítások végrehajtásakor minden módosítás után mindenképpen tegye közzé újra a fejlesztői portált, mivel a releváns módosítások (például a hatókör módosítása) egyébként nem propagálhatók a portálon, és később használhatók az API-k kipróbálására.

API konfigurálása OAuth 2.0-s felhasználói engedélyezés használatára

Az OAuth 2.0-kiszolgáló konfigurációjának mentése után konfiguráljon egy API-t vagy API-t a konfiguráció használatára.

Fontos

• Az API OAuth 2.0 felhasználói engedélyezési beállításainak konfigurálása lehetővé teszi, hogy az API Management jogkivonatot szerezzen be az engedélyezési kiszolgálóról, amikor az Azure Portalon vagy a fejlesztői portálon használja a tesztkonzolt. Az engedélyezési kiszolgáló beállításai az API-definícióhoz és a dokumentációhoz is hozzáadódnak.
• Az OAuth 2.0 futtatókörnyezetben történő engedélyezéséhez az ügyfélalkalmazásnak be kell szereznie és be kell mutatnia a jogkivonatot, és konfigurálnia kell a tokenérvényesítést az API Managementben vagy a háttér API-ban. Példa: API védelme az Azure API Managementben OAuth 2.0-hitelesítéssel Microsoft Entra-azonosítóval.

1. Válassza ki az API-kat a bal oldali API Management menüből.

2. Válassza ki a kívánt API nevét, és válassza a Gépház lapot. Görgessen a Biztonság szakaszhoz, majd válassza az OAuth 2.0 lehetőséget.

3. Válassza ki a kívánt engedélyezési kiszolgálót a legördülő listából, és válassza a Mentés lehetőséget.

   

Fejlesztői portál – az OAuth 2.0 felhasználói engedélyezésének tesztelése

Miután konfigurálta az OAuth 2.0 engedélyezési kiszolgálót, és konfigurálta az API-t a kiszolgáló használatára, tesztelheti a fejlesztői portálon, és meghívhat egy API-t.

1. Az Azure API Management-példány áttekintési lapján válassza a Fejlesztői portál lehetőséget a felső menüben.

2. Keresse meg az API bármely műveletét a fejlesztői portálon.

3. Válassza a Kipróbálás lehetőséget a fejlesztői konzolra való ugráshoz.

4. Jegyezze fel az Imént hozzáadott engedélyezési kiszolgálónak megfelelő új elemet az Engedélyezés szakaszban.

5. Válassza ki az engedélyezési kódot az engedélyezési legördülő listából.

   

6. Miután a rendszer rákérdezett, jelentkezzen be a Microsoft Entra-bérlőbe.

   • Ha már bejelentkezett a fiókba, előfordulhat, hogy a rendszer nem kéri.

7. A sikeres bejelentkezés után a rendszer hozzáad egy Authorization fejlécet a kéréshez, a Microsoft Entra ID-ból származó hozzáférési jogkivonattal. A következő egy rövidített minta jogkivonat (Base64 kódolású):

   Authorization: Bearer eyJ0eXAiOi[...]3pkCfvEOyA
   

8. Konfigurálja a fennmaradó paraméterek kívánt értékeit, és válassza a Küldés lehetőséget az API meghívásához.

JWT érvényesítési szabályzat konfigurálása a kérések előzetes engedélyezéséhez

Az eddigi konfigurációban az API Management nem érvényesíti a hozzáférési jogkivonatot. Csak az engedélyezési fejlécben lévő jogkivonatot továbbítja a háttér API-nak.

A kérelmek előzetes engedélyezéséhez konfiguráljon egy validate-jwt szabályzatot az egyes bejövő kérések hozzáférési jogkivonatának érvényesítéséhez. Ha egy kérelem nem rendelkezik érvényes jogkivonattal, az API Management letiltja azt.

Az alábbi példaszabályzat a <inbound> szabályzatszakaszhoz hozzáadva ellenőrzi a célközönség jogcímének értékét egy, az Engedélyezés fejlécben található Microsoft Entra-azonosítóból beszerzett hozzáférési jogkivonatban. Hibaüzenetet ad vissza, ha a jogkivonat érvénytelen. Konfigurálja ezt a szabályzatot a forgatókönyvnek megfelelő szabályzat hatókörében.

• openid-config Az URL-címben ez aad-tenant a Microsoft Entra-azonosító bérlőazonosítója. Keresse meg ezt az értéket az Azure Portalon, például a Microsoft Entra-erőforrás Áttekintés lapján. Az alábbi példa egy egybérlős Microsoft Entra-alkalmazást és egy v2-konfigurációs végpontot feltételez.
• Az érték a claim Microsoft Entra ID-ban regisztrált háttéralkalmazás ügyfél-azonosítója.

<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>

Feljegyzés

Az előző openid-config URL-cím a v2-végpontnak felel meg. A v1 openid-config végponthoz használja a következőt https://login.microsoftonline.com/{aad-tenant}/.well-known/openid-configuration: .

A szabályzatok konfigurálásáról további információt a Szabályzatok beállítása vagy szerkesztése című témakörben talál. A JWT-érvényesítések további testreszabásához tekintse meg a validate-jwt referenciát. A Microsoft Entra szolgáltatás által biztosított JWT érvényesítéséhez az API Management a szabályzatot validate-azure-ad-token is biztosítja.

Kapcsolódó tartalom

• További információ az OAuth 2.0 és az API Management használatáról: Webes API-háttérrendszer védelme az Azure API Managementben OAuth 2.0-hitelesítéssel a Microsoft Entra-azonosítóval.

• További információ a Microsoft Identitásplatform és az OAuth 2.0 engedélyezési kódfolyamatáról