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

Jak jako vývojář zajistíte, nulová důvěra (Zero Trust), 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. V přístupovém tokenu, který aplikace poskytuje při volání rozhraní API, by kontrolovala deklarace identity subjektu (sub) nebo ID objektu (oid) a ID tenanta (svázané). Rozhraní API nespoléhá na nedůvěryhodnou aplikaci, což je jen volání pocházející z nějakého umístění v síti. Místo toho ověří token, aby se zajistilo, že rozhraní API funguje pouze jménem uživatele aplikace, který ověřil Microsoft Entra ID.

Když jedno rozhraní API (označujeme ho jako původní rozhraní API), je důležité, aby rozhraní API, které voláme (označujeme ho jako podřízené rozhraní API), postupoval podle výše popsaného procesu 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. Původní rozhraní API se pak stane jedinou autoritou, pro kterou by uživatelé mohli dosáhnout výsledků v podřízeném rozhraní API. Původní rozhraní API by mohlo záměrně (nebo neúmyslně) umožnit uživateli provést úlohu, kterou uživatel nemohl 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.

Klientská aplikace získá přístupový token pro volání původního rozhraní API.

Následující diagram znázorňuje klientskou aplikaci a původní rozhraní API.

Název diagramu: Klientská aplikace získala přístupový token pro volání původního rozhraní API. Podnadpis diagramu: Klientská aplikace má přístupový token A, který umožňuje pracovat jménem uživatele identifikovaného v tokenu pro volání původního rozhraní API.

Klientská aplikace získala delegovaný přístupový token oprávnění (označený tvarem pětiúhelníku s popiskem A) do původního 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.

Klientská aplikace poskytuje přístupový token k původnímu rozhraní API.

Následující animace ukazuje klientskou aplikaci, která uděluje přístupový token původnímu rozhraní API. Původní rozhraní API plně ověří a zkontroluje přístupový token a určí identitu uživatele klientské aplikace.

Animovaný diagram znázorňuje dva diagramy s přechodem pohybu mezi prvním a druhým diagramem. První název diagramu: Klientská aplikace získala přístupový token pro volání původního rozhraní API. První podnadpis diagramu: Klientská aplikace má přístupový token A, který umožňuje pracovat jménem uživatele identifikovaného v tokenu pro volání původního rozhraní API. Název druhého diagramu: Klientská aplikace poskytuje přístupový token k původnímu rozhraní API.

Původní rozhraní API provádí ověřování a vynucování tokenů.

Další animace ukazuje, že jakmile klientská aplikace poskytne přístupový token 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.

Animovaný diagram znázorňuje dva diagramy s přechodem pohybu mezi prvním a druhým diagramem. První název diagramu: Klientská aplikace poskytuje přístupový token k původnímu rozhraní API. Název druhého diagramu: Původní rozhraní API provádí ověřování a vynucování tokenů. Pokud je to všechno v pořádku, rozhraní API pokračuje a obsluhuje požadavek.

Původní rozhraní API nemůže použít přístupový token k volání podřízené rozhraní API

Následující animace ukazuje, že původní rozhraní API teď 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.

Animovaný diagram znázorňuje dva diagramy s přechodem pohybu mezi prvním a druhým diagramem. První název diagramu: Původní rozhraní API chce volat podřízené rozhraní API. Název druhého diagramu: Původní rozhraní API nemůže použít token k volání podřízeného rozhraní API.

Původní rozhraní API se vrátí zpět do Microsoft Entra ID.

V následující animaci se původní rozhraní API musí vrátit k ID Microsoft Entra. Potřebuje přístupový token pro volání podřízeného rozhraní API jménem uživatele.

Animovaný diagram znázorňuje dva diagramy s přechodem pohybu mezi prvním a druhým diagramem. První název diagramu: Původní rozhraní API nemůže použít token k volání podřízeného rozhraní API. Název druhého diagramu: Původní rozhraní API se vrátí k ID Microsoft Entra. Podnadpis druhého diagramu: Potřebuje přístupový token pro volání podřízeného rozhraní API jménem uživatele.

Další animace ukazuje původní rozhraní API poskytující token, který původní rozhraní API přijalo z klientské aplikace a přihlašovací údaje klienta původního rozhraní API.

Animovaný diagram znázorňuje dva diagramy s přechodem pohybu mezi prvním a druhým diagramem. První název diagramu: Původní rozhraní API se vrátí do Microsoft Entra ID. První podnadpis diagramu: Potřebuje přístupový token pro volání podřízeného rozhraní API jménem uživatele. Název druhého diagramu: Původní rozhraní API se vrátí k ID Microsoft Entra. Podnadpis druhého diagramu: Poskytuje token z klientské aplikace a přihlašovací údaje pro původní rozhraní API.

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 deklarací identity a vrátili byste se k volající aplikaci s informacemi týkajícími se nedodržování souhlasu (například související se zásadami podmíněného přístupu).

ID Microsoft Entra provádí kontroly

V následující animaci provede MICROSOFT Entra ID své kontroly. 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.

Animovaný diagram znázorňuje dva diagramy s přechodem pohybu mezi prvním a druhým diagramem. První název diagramu: Původní rozhraní API se vrátí do Microsoft Entra ID. První podnadpis diagramu: Poskytuje token z klientské aplikace a přihlašovací údaje pro původní rozhraní API. Název druhého diagramu: Microsoft Entra ID kontroluje podmíněný přístup, souhlas atd. Podnadpis druhého diagramu: Původní rozhraní API obdrží vlastní přístupový token pro volání podřízeného rozhraní API jménem uživatele, který se přihlásil k klientské aplikaci.

Původní rozhraní API má kontext uživatele s tokem On-Behalf-Of

Následující animace znázorňuje proces toku On-Behalf-Of (OBO), který umožňuje rozhraní API i nadále mít kontext uživatele, protože volá podřízené rozhraní API.

Animovaný diagram znázorňuje dva diagramy s přechodem pohybu mezi prvním a druhým diagramem. První název diagramu: Proces toku On-Behalf-Of umožňuje původnímu rozhraní API pokračovat v kontextu uživatele, protože volá podřízené rozhraní API. Druhý název diagramu: Proces toku On-Behalf-Of umožňuje původnímu rozhraní API pokračovat v kontextu uživatele, protože volá podřízené rozhraní API.

Původní volání rozhraní API pro podřízené rozhraní API

V další animaci zavoláme 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.

Animovaný diagram znázorňuje dva diagramy s přechodem pohybu mezi prvním a druhým diagramem. První název diagramu: Proces toku On-Behalf-Of umožňuje původnímu rozhraní API pokračovat v kontextu uživatele, protože volá podřízené rozhraní API. Název druhého diagramu: Volá se podřízené rozhraní API. Podnadpis druhého diagramu: Token, který přijímá podřízené rozhraní API, má správné deklarace identity pro identifikaci uživatele klientské aplikace.

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

Tato poslední animace ukazuje, že nejlepší možností je, aby původní rozhraní API provádělo tok On-Behalf-Of (OBO). Pokud podřízené rozhraní API obdrží správný token, může správně reagovat.

Animovaný diagram znázorňuje dva diagramy s přechodem pohybu mezi prvním a druhým diagramem. Název prvního diagramu: Volá se podřízené rozhraní API. První podnadpis diagramu: Token, který přijímá podřízené rozhraní API, má správné deklarace identity pro identifikaci uživatele klientské aplikace. Druhý název diagramu: Nejlepší možností je, aby původní rozhraní API provádělo "jménem toku". 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í vašich cílů nulová důvěra (Zero Trust).
• 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í a současně se zvýšilo zabezpečení nulové důvěryhodnosti aplikace 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 (používané pro implicitní toky), certifikáty a tajné kódy, identifikátor URI ID aplikace a vlastnictví aplikace.
• Knihovny ověřování platformy Microsoft Identity Platform popisují podporu microsoft Authentication Library pro různé typy aplikací.