API meghívása másik API-ból

Hogyan biztosíthatja fejlesztőként, hogy Teljes felügyelet, ha van egy API, amelyet egy másik API-nak kell meghívnia? Ebben a cikkben megtudhatja, hogyan fejlesztheti biztonságosan az alkalmazást, ha az egy felhasználó nevében dolgozik.

Amikor egy felhasználó egy alkalmazás felhasználói felületét használja, az alkalmazás delegált engedélyt használhat, hogy az API tudja, melyik felhasználó nevében dolgozik az alkalmazás. Megvizsgálná a tulajdonosi (al)jogcímet vagy objektumazonosítót (oid) és bérlőazonosítót (tid) a hozzáférési jogkivonatban, amelyet az alkalmazás az API meghívásakor biztosít. Az API nem támaszkodna a nem megbízható alkalmazásra, ami csak egy hívás, amely a hálózaton belülről érkezik. Ehelyett érvényesítené a jogkivonatot, hogy az API csak annak az alkalmazásfelhasználónak a nevében működjön, amelyet a Microsoft Entra ID ellenőrzött.

Amikor az egyik API (eredeti API-ként hivatkozunk rá) meghív egy másikat, létfontosságú, hogy a hívott API (a downstream API-ként hivatkozunk rá) kövesse a fent leírt ellenőrzési folyamatot. A Downstream API nem támaszkodhat nem megbízható hálózati forrásra. A felhasználói identitást megfelelően érvényesített hozzáférési jogkivonatból kell lekérnie.

Ha a Downstream API nem követi a megfelelő érvényesítési folyamatot, a Downstream API-nak az Eredeti API-ra kell támaszkodnia, hogy más módon biztosítsa a felhasználó identitását. Előfordulhat, hogy a Downstream API helytelenül használ alkalmazásengedélyt a művelet végrehajtásához. Ezután az Eredeti API lesz az egyetlen hatóság, amely felett a felhasználók elérnék a downstream API-val szembeni eredményeket. Az eredeti API szándékosan (vagy akaratlanul) lehetővé teheti a felhasználó számára egy olyan feladat elvégzését, amelyet a felhasználó egyébként nem tudott elvégezni. Az egyik felhasználó módosíthatja például egy másik felhasználó adatait, vagy elolvashatja és frissítheti azokat a dokumentumokat, amelyekhez a felhasználó nem rendelkezik hozzáférési engedéllyel. A nem megfelelő ellenőrzés súlyos biztonsági problémákat okozhat.

A nagyobb biztonság érdekében az Eredeti API egy delegált jogosultsági hozzáférési jogkivonatot szerez be a Downstream API számára a hívás során. Nézzük meg, hogyan működik ez.

Az ügyfélalkalmazás hozzáférési jogkivonatot szerez be az Eredeti API meghívásához

Az alábbi ábrán az Ügyfélalkalmazás és az Eredeti API látható.

Diagram címe: Az ügyfélalkalmazás egy hozzáférési jogkivonatot szerzett be az Eredeti API meghívásához. Diagram alcím: Az ügyfélalkalmazás rendelkezik egy "A" hozzáférési jogkivonattal, amely lehetővé teszi, hogy a jogkivonatban azonosított felhasználó nevében működjön az Eredeti API meghívásához.

Az ügyfélalkalmazás beszerzett egy delegált jogosultsági hozzáférési jogkivonatot (amelyet a pentagon alakzat "A" címkével jelöl) az Eredeti API-nak. A delegált engedélyhozzáférési jogkivonat lehetővé teszi, hogy a felhasználó nevében működve meghívja az engedélyezést igénylő eredeti API-t.

Az ügyfélalkalmazás hozzáférési jogkivonatot biztosít az Eredeti API-hoz

Az alábbi animáció azt mutatja be, hogy az ügyfélalkalmazás megadja a hozzáférési jogkivonatot az Eredeti API-nak. Az Eredeti API teljes mértékben ellenőrzi és megvizsgálja a hozzáférési jogkivonatot az ügyfélalkalmazás felhasználójának identitásának meghatározásához.

Az animált diagram két diagramot mutat be, az első és a második diagram közötti mozgásáttűnéssel. Első diagram címe: Az ügyfélalkalmazás egy hozzáférési jogkivonatot szerzett be az Eredeti API meghívásához. Első diagram alcím: Az ügyfélalkalmazás rendelkezik egy hozzáférési "A" jogkivonattal, amely lehetővé teszi, hogy a jogkivonatban azonosított felhasználó nevében működjön az Eredeti API meghívásához. Második diagramcím: Az ügyfélalkalmazás a hozzáférési jogkivonatot az eredeti API-hoz adja.

Az eredeti API jogkivonat-érvényesítési és -kényszerítési műveleteket hajt végre

A következő animáció azt mutatja be, hogy miután az Ügyfélalkalmazás megadta a hozzáférési jogkivonatot az Eredeti API-nak, az Eredeti API jogkivonat-érvényesítést és kényszerítést hajt végre. Ha minden rendben van, az API folytatja és szolgáltatásokat nyújt az ügyfélalkalmazásra vonatkozó kérésnek.

Az animált diagram két diagramot mutat be, az első és a második diagram közötti mozgásáttűnéssel. Első diagram címe: Az ügyfélalkalmazás a hozzáférési jogkivonatot az eredeti API-hoz adja. Második diagram címe: Az eredeti API jogkivonat-ellenőrzést és -kényszerítéseket hajt végre. Ha minden rendben van, az API folytatja és szolgáltatásokat nyújt a kérésnek.

Az eredeti API nem tud hozzáférési jogkivonatot használni a Downstream API meghívásához

Az alábbi animáció azt mutatja be, hogy az Eredeti API most egy downstream API-t szeretne meghívni. Az Eredeti API azonban nem tudja használni a hozzáférési jogkivonatot a Downstream API meghívásához.

Az animált diagram két diagramot mutat be, az első és a második diagram közötti mozgásáttűnéssel. Az első diagram címe: Az eredeti API alsóbb rétegbeli API-t szeretne meghívni. Második diagram címe: Az eredeti API nem tudja használni a jogkivonatot a Downstream API meghívásához.

Az eredeti API visszatér a Microsoft Entra-azonosítóhoz

A következő animációban az Eredeti API-nak vissza kell lépnie a Microsoft Entra-azonosítóhoz. Hozzáférési jogkivonatra van szüksége ahhoz, hogy meghívja a Downstream API-t a felhasználó nevében.

Az animált diagram két diagramot mutat be, az első és a második diagram közötti mozgásáttűnéssel. Első diagram címe: Az eredeti API nem tudja használni a jogkivonatot a Downstream API meghívásához. Második diagram címe: Az eredeti API a Microsoft Entra-azonosítóra kerül vissza. Második ábra alcíme: Hozzáférési jogkivonatra van szükség a Downstream API meghívásához a felhasználó nevében.

A következő animáció az Eredeti API-t mutatja be, amely az eredeti API által az ügyfélalkalmazástól kapott jogkivonatot és az eredeti API ügyfél-hitelesítő adatait tartalmazza.

Az animált diagram két diagramot mutat be, az első és a második diagram közötti mozgásáttűnéssel. Az első diagram címe: Az eredeti API a Microsoft Entra-azonosítóra kerül vissza. Első ábra alcíme: Hozzáférési jogkivonatra van szüksége a downstream API meghívásához a felhasználó nevében. Második diagram címe: Az eredeti API a Microsoft Entra-azonosítóra kerül vissza. Második diagram alcím: Az ügyfélalkalmazás jogkivonatát és az eredeti API hitelesítő adatait tartalmazza.

A Microsoft Entra-azonosító olyan dolgokat keres, mint a hozzájárulás vagy a feltételes hozzáférés kényszerítése. Előfordulhat, hogy vissza kell mennie a hívó ügyfélhez, és meg kell adnia annak okát, hogy nem tudja lekérni a jogkivonatot. Általában egy jogcím-kihívási folyamatot használva visszatérhet a hívó alkalmazáshoz a nem fogadott hozzájárulásra vonatkozó információkkal (például feltételes hozzáférési szabályzatokkal).

A Microsoft Entra ID ellenőrzéseket végez

Az alábbi animációban a Microsoft Entra ID elvégzi az ellenőrzéseket. Ha minden rendben van, a Microsoft Entra ID egy hozzáférési jogkivonatot ad ki az eredeti API-hoz, hogy meghívja a Downstream API-t a felhasználó nevében.

Az animált diagram két diagramot mutat be, az első és a második diagram közötti mozgásáttűnéssel. Az első diagram címe: Az eredeti API a Microsoft Entra-azonosítóra kerül vissza. Első diagram alcím: Az ügyfélalkalmazás jogkivonatát és az eredeti API hitelesítő adatait tartalmazza. Második ábra címe: A Microsoft Entra-azonosító ellenőrzi a feltételes hozzáférést, a hozzájárulást stb. Második ábra alcíme: Az eredeti API saját hozzáférési jogkivonatot kap a Downstream API meghívásához az ügyfélalkalmazásba bejelentkezett felhasználó nevében.

Az eredeti API felhasználói környezettel rendelkezik a folyamat nevében

Az alábbi animáció bemutatja a folyamat nevében ( OBO) folyamatot, amely lehetővé teszi, hogy az API továbbra is a felhasználói környezettel rendelkezzen a Downstream API hívása közben.

Az animált diagram két diagramot mutat be, az első és a második diagram közötti mozgásáttűnéssel. Az első diagram címe: A folyamat nevében történő folyamat lehetővé teszi, hogy az eredeti API továbbra is felhasználói környezettel rendelkezzen a downstream API meghívása során. Második diagram címe: A folyamat nevében történő folyamat lehetővé teszi, hogy az eredeti API továbbra is felhasználói környezettel rendelkezzen, miközben a downstream API-t hívja.

Az eredeti API meghívja a Downstream API-t

A következő animációban a Downstream API-t hívjuk meg. A Downstream API által kapott jogkivonat rendelkezik a megfelelő célközönségi (aud) jogcímvel, amely a Downstream API-t jelzi.

Az animált diagram két diagramot mutat be, az első és a második diagram közötti mozgásáttűnéssel. Az első diagram címe: A folyamat nevében történő folyamat lehetővé teszi, hogy az eredeti API továbbra is felhasználói környezettel rendelkezzen a downstream API meghívása során. Második diagram címe: A downstream API neve. Második ábra alcíme: A Downstream API által kapott jogkivonat megfelelő jogcímekkel rendelkezik az ügyfélalkalmazás felhasználójának azonosításához.

A jogkivonat tartalmazza a megadott hozzájárulás hatóköreit és az alkalmazás eredeti felhasználói identitását. A Downstream API megfelelően képes érvényes engedélyeket implementálni annak biztosítása érdekében, hogy az azonosított felhasználó rendelkezik engedéllyel a kért feladat végrehajtásához. A folyamat nevében szeretne jogkivonatokat szerezni egy API-hoz, hogy meghívjon egy másik API-t, hogy meggyőződjön arról, hogy a felhasználói környezet minden alsóbb rétegbeli API-nak átadódik.

Legjobb lehetőség: Az eredeti API a folyamat nevében hajtja végre a folyamatot

Ez az utolsó animáció azt mutatja be, hogy a legjobb megoldás az eredeti API-nak az on-behalf-of flow (OBO) végrehajtása. Ha a Downstream API megkapja a megfelelő jogkivonatot, megfelelően tud válaszolni.

Az animált diagram két diagramot mutat be, az első és a második diagram közötti mozgásáttűnéssel. Az első diagram címe: A downstream API neve. Első ábra alcíme: A Downstream API által kapott jogkivonat megfelelő jogcímekkel rendelkezik az ügyfélalkalmazás felhasználójának azonosításához. Második diagramcím: A legjobb megoldás, ha az Eredeti API "a folyamat nevében" hajt végre. Ha a Downstream API megkapja a megfelelő jogkivonatot, megfelelően tud válaszolni.

Ha egy API egy felhasználó nevében jár el, és egy másik API-t kell meghívnia, az API-nak az OBO használatával kell beszereznie egy delegált jogosultsági hozzáférési jogkivonatot a downstream API felhasználó nevében történő meghívásához. Az API-k soha nem használhatnak alkalmazásengedélyeket a downstream API-k meghívására, amikor az API egy felhasználó nevében jár el.

Következő lépések

• Microsoft Identitásplatform hitelesítési folyamatok > alkalmazásforgatókönyvek ismertetik a hitelesítési folyamatokat és azokat az alkalmazásforgatókönyveket, amelyekben használják őket.
• Az API Protection ismerteti az API regisztrációval, engedélyek és hozzájárulások meghatározásával, valamint a hozzáférés kényszerítésével kapcsolatos ajánlott eljárásokat a Teljes felügyelet célok elérése érdekében.
• Példa a Microsoft identitás-jóváhagyási keretrendszer által védett API-ra, amely segít a minimális jogosultsági szintű alkalmazásengedélyezési stratégiák kialakításában a legjobb felhasználói élmény érdekében.
• A jogkivonatok testreszabása a Microsoft Entra-jogkivonatokban kapott információkat ismerteti. Ez a cikk bemutatja, hogyan szabhatja testre a jogkivonatokat a rugalmasság és az ellenőrzés javítása érdekében, miközben a minimális jogosultsággal rendelkező alkalmazásmegbízhatósági biztonságot növeli.
• Az egyéni API-k biztonságossá tétele a Microsoft Identity Learn modullal bemutatja, hogyan lehet biztonságossá tenni egy webes API-t a Microsoft-identitással, és hogyan hívhatja meg egy másik alkalmazásból.
• Az alkalmazástulajdonságok biztonsági ajánlott eljárásai az átirányítási URI-t, a hozzáférési jogkivonatokat (implicit folyamatokhoz), a tanúsítványokat és titkos kulcsokat, az alkalmazásazonosító URI-t és az alkalmazás tulajdonjogát ismertetik.
• Microsoft Identitásplatform hitelesítési kódtárak a Microsoft Authentication Library különböző alkalmazástípusok támogatását ismertetik.