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

Hogyan biztosíthatja fejlesztőként a zéró megbízhatóságot , 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. Az alkalmazás által az API meghívása során biztosított hozzáférési jogkivonatban vizsgálja meg a tulajdonosi (sub) jogcím- vagy objektumazonosító (oid) és bérlőazonosító (tid) jogcímeket. Az API nem támaszkodik a nem megbízható alkalmazásra, ami csak egy hívás, amely a hálózaton belülről érkezik. Ehelyett ellenőrzi 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, elengedhetetlen, hogy a meghívni kívánt API (a downstream API-ként hivatkozunk rá) kövesse az érvényesíté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 tudják érni, hogy melyik eredményt érjék el a Downstream API-val szemben. Az Eredeti API szándékosan (vagy akaratlanul) lehetővé teszi a felhasználó számára, hogy olyan feladatot hajthasson végre, amelyet a felhasználó egyébként nem tud 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.

1. Az ügyfélalkalmazás hozzáférési jogkivonatot szerez be az Eredeti API meghívásához. Az ügyfélalkalmazás delegált jogosultsági hozzáférési jogkivonatot szerez be az Eredeti API-hoz. 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.
2. Az ügyfélalkalmazás hozzáférési jogkivonatot biztosít az Eredeti API-hoz. 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.
3. Az eredeti API jogkivonat-ellenőrzést és -érvényesítést hajt végre. 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.
4. Az eredeti API nem tud hozzáférési jogkivonatot használni a Downstream API meghívásához. Az eredeti API alsóbb rétegbeli 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.
5. Az eredeti API visszatér a Microsoft Entra-azonosítóhoz. 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 Eredeti API biztosítja az eredeti API által az ügyfélalkalmazástól kapott jogkivonatot és az eredeti API ügyfél-hitelesítő adatait.
6. A Microsoft Entra ID ellenőrzéseket végez. 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 jogosultsági kihívás folyamatot alkalmazna, hogy visszajelezzen a hívó alkalmazásnak a meg nem kapott hozzájárulásra vonatkozó információkkal kapcsolatban (például amikor feltételes hozzáférési szabályzatok érintettek). 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.
7. Az eredeti API tartalmazza a felhasználói kontextust az On-Behalf-Of folyamatban. A On-Behalf-Of flow (OBO) folyamat lehetővé teszi, hogy az API továbbra is a felhasználói kontextussal rendelkezzen a Downstream API hívása közben.
8. Az eredeti API meghívja a Downstream API-t. Hívja meg a Downstream API-t. A Downstream API által kapott jogkivonat rendelkezik a megfelelő célközönségi (aud) jogcímvel, amely a Downstream API-t jelzi. 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

A legjobb megoldás, ha az Eredeti API végrehajtja az On-Behalf-Of folyamatot (OBO). 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

• A Microsoft identitásplatform hitelesítési folyamatai > alkalmazásforgatókönyvek a hitelesítési folyamatokat és azokat az alkalmazásforgatókönyveket ismertetik, amelyekben használják őket.
• Az API Protection bemutatja az API regisztrációval, engedélyek és hozzájárulások meghatározásával, valamint a hozzáférés kikényszerítésével kapcsolatos ajánlott eljárásokat a zéró megbízhatósági 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.
• Tokenek testreszabása ismerteti a Microsoft Entra tokenekben található információkat. Ez a cikk bemutatja, hogyan szabhatja testre a tokeneket a rugalmasság és a szabályozás javítása érdekében, miközben a legkisebb jogosultságokkal rendelkező Zero Trust 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, a tanúsítványokat és titkos kulcsokat, az alkalmazásazonosító URI-t és az alkalmazás tulajdonjogát ismertetik.
• A Microsoft identitásplatform-hitelesítési kódtárai a Microsoft Authentication Library különböző alkalmazástípusokhoz való támogatását ismertetik.