Volání rozhraní API z jiného rozhraní API

Jak jako vývojář zajistíte nulovou důvěryhodnost , když máte jedno rozhraní API, které potřebuje volat jiné rozhraní API? V tomto článku se dozvíte, jak bezpečně vyvíjet aplikaci, když pracuje jménem uživatele.

Když uživatel řídí uživatelské rozhraní aplikace, může aplikace používat delegovaná oprávnění, aby rozhraní API vědělo, na kterém uživateli, jehož jménem aplikace funguje. Kontroluje deklaraci identity subjektu (sub) nebo ID objektu (oid) a ID tenanta (tid) v přístupovém tokenu, který aplikace poskytuje při volání rozhraní API. Rozhraní API nespoléhá na nedůvěryhodnou aplikaci, což pouze znamená volání pocházející z nějakého zdroje v síti. Místo toho ověří token, aby se zajistilo, že rozhraní API funguje jenom jménem uživatele aplikace, který ověřil Microsoft Entra ID.

Když jedno rozhraní API (označujeme ho jako původní rozhraní API) volá jiné, je zásadní, aby rozhraní API, které voláme (označujeme ho jako podřízené rozhraní API), dodržovalo postup ověřování. Podřízené rozhraní API nemůže spoléhat na nedůvěryhodný zdroj sítě. Musí získat identitu uživatele z správně ověřeného přístupového tokenu.

Pokud podřízené rozhraní API nedodržuje správný proces ověřování, musí podřízené rozhraní API spoléhat na původní rozhraní API a poskytnout identitu uživatele jiným způsobem. Podřízené rozhraní API může k provedení operace nesprávně použít oprávnění aplikace. Pak se původní rozhraní API stane jedinou autoritou, která určuje, kteří uživatelé mohou dosáhnout jakých výsledků v podřízeném rozhraní API. Původní rozhraní API může záměrně (nebo neúmyslně) umožnit uživateli provést úlohu, kterou uživatel nemůže jinak provést. Jeden uživatel může například změnit podrobnosti o jiném uživateli nebo číst a aktualizovat dokumenty, ke kterým uživatel nemá oprávnění k přístupu. Nesprávné ověření může způsobit vážné problémy se zabezpečením.

Pro lepší zabezpečení získá původní rozhraní API delegovaný přístupový token oprávnění, který se poskytne podřízené rozhraní API při volání původního rozhraní API. Pojďme si projít, jak to funguje.

1. Klientská aplikace získá přístupový token pro volání původního rozhraní API. Klientská aplikace získá delegovaný přístupový token oprávnění k původnímu rozhraní API. Delegovaný přístupový token oprávnění umožňuje pracovat jménem uživatele, aby volal původní rozhraní API, které vyžaduje autorizaci.
2. Klientská aplikace poskytuje přístupový token k původnímu rozhraní API. Klientská aplikace poskytuje přístupový token k původnímu rozhraní API. Původní rozhraní API plně ověří a zkontroluje přístupový token a určí identitu uživatele klientské aplikace.
3. Původní rozhraní API provádí ověřování a vynucování tokenů. Jakmile klientská aplikace udělí přístupový token k původnímu rozhraní API, původní rozhraní API provede ověření a vynucování tokenu. Pokud je vše v pořádku, rozhraní API pokračuje a obsluhuje požadavek na klientskou aplikaci.
4. Původní rozhraní API nemůže použít přístupový token k volání podřízené rozhraní API. Původní rozhraní API chce volat podřízené rozhraní API. Původní rozhraní API ale nemůže použít přístupový token k volání podřízeného rozhraní API.
5. Původní rozhraní API se vrátí do Microsoft Entra ID. Původní rozhraní API se musí přepnout zpět na Microsoft Entra ID. Potřebuje přístupový token pro volání podřízeného rozhraní API jménem uživatele. Původní rozhraní API poskytuje token, který původní rozhraní API přijalo z klientské aplikace a přihlašovací údaje klienta původního rozhraní API.
6. ID Microsoft Entra provádí kontroly. Microsoft Entra ID kontroluje věci, jako je souhlas nebo vynucení podmíněného přístupu. Možná se budete muset vrátit ke svému volajícímu klientovi a poskytnout důvod, proč token nemůžete získat. Obvykle byste použili proces výzvy na deklaraci a vrátili byste se k volající aplikaci s informacemi o tom, že souhlas nebyl obdržen (například související se zásadami podmíněného přístupu). Pokud je všechno v pořádku, Microsoft Entra ID vydá přístupový token k původnímu rozhraní API pro volání podřízeného rozhraní API jménem uživatele.
7. Původní rozhraní API má kontext uživatele s tokem On-Behalf-Of. Proces On-Behalf-Of flow (OBO) umožňuje rozhraní API i nadále mít kontext uživatele, protože volá následné rozhraní API.
8. Původní rozhraní API volá podřízené rozhraní API. Zavolejte podřízené rozhraní API Token, který přijímá podřízené rozhraní API, má správnou cílovou skupinu (aud), která označuje podřízené rozhraní API. Token zahrnuje rozsahy uděleného souhlasu a původní identitu uživatele aplikace. Podřízené rozhraní API může správně implementovat efektivní oprávnění, aby se zajistilo, že identifikovaný uživatel má oprávnění k provedení požadované úlohy. Chcete použít jménem toku k získání tokenů pro rozhraní API k volání jiného rozhraní API, aby se zajistilo, že kontext uživatele předá všem podřízeným rozhraním API.

Nejlepší možnost: Původní rozhraní API provádí tok On-Behalf-Of

Nejlepší možností je, aby Původní API provádělo tokBehalf-Of (OBO). Pokud podřízené rozhraní API obdrží správný token, může správně reagovat. Pokud rozhraní API působí jménem uživatele a potřebuje volat jiné rozhraní API, musí rozhraní API použít OBO k získání delegovaného přístupového tokenu oprávnění k volání podřízeného rozhraní API jménem uživatele. Rozhraní API by nikdy neměla používat oprávnění aplikace k volání podřízených rozhraní API, pokud rozhraní API působí jménem uživatele.

Další kroky

• Scénáře ověřování platformy Microsoft Identity Platform a aplikace popisují toky ověřování a scénáře aplikací, ve kterých se používají.
• Služba API Protection popisuje osvědčené postupy pro ochranu rozhraní API prostřednictvím registrace, definování oprávnění a souhlasu a vynucování přístupu k dosažení cílů nulové důvěryhodnosti.
• Příklad rozhraní API chráněného rozhraním Microsoft Identity Consent Framework vám pomůže navrhnout strategie oprávnění aplikací s nejnižšími oprávněními pro co nejlepší uživatelské prostředí.
• Přizpůsobení tokenů popisuje informace, které můžete přijímat v tokenech Microsoft Entra. Vysvětluje, jak přizpůsobit tokeny, aby se zlepšila flexibilita a řízení při zvýšení zabezpečení nulové důvěryhodnosti aplikací s nejnižšími oprávněními.
• Modul Zabezpečené vlastní rozhraní API s Microsoft Identity Learn vysvětluje, jak zabezpečit webové rozhraní API s identitou Microsoftu a jak ho volat z jiné aplikace.
• Osvědčené postupy zabezpečení pro vlastnosti aplikace popisují identifikátor URI přesměrování, přístupové tokeny, certifikáty a tajné kódy, identifikátor URI ID aplikace a vlastnictví aplikace.
• Knihovny ověřování platformy Microsoft Identity popisují podporu knihovny Microsoft Authentication Library pro různé typy aplikací.