Wywoływanie interfejsu API z innego interfejsu API
Jak, jako deweloper, upewnij się, że zero trust, gdy masz jeden interfejs API, który musi wywoływać inny interfejs API? Z tego artykułu dowiesz się, jak bezpiecznie opracowywać aplikację podczas jej pracy w imieniu użytkownika.
Gdy użytkownik kieruje interfejsem użytkownika aplikacji, aplikacja może używać delegowanego uprawnienia, aby interfejs API wiedział, którego użytkownika w imieniu aplikacji działa. Spowoduje to sprawdzenie oświadczenia podmiotu (sub) lub identyfikatora obiektu (oid) i oświadczeń identyfikatora dzierżawy (tid) w tokenie dostępu, który aplikacja udostępnia podczas wywoływania interfejsu API. Interfejs API nie polegałby na niezaufanej aplikacji, która jest tylko wywołaniem pochodzącym z gdzieś w sieci. Zamiast tego zweryfikuje token, aby upewnić się, że interfejs API działa tylko w imieniu użytkownika aplikacji zweryfikowanego przez firmę Microsoft Entra ID.
Gdy jeden interfejs API (nazywamy go oryginalnym interfejsem API) wywołuje inny, ważne jest, aby wywoływany interfejs API (nazywamy go interfejsem API podrzędnym) był zgodny z opisanym powyżej procesem weryfikacji. Interfejs API podrzędny nie może polegać na niezaufanym źródle sieci. Musi ona pobrać tożsamość użytkownika z prawidłowo zweryfikowanego tokenu dostępu.
Jeśli interfejs API podrzędny nie jest zgodny z odpowiednim procesem walidacji, interfejs API podrzędny musi polegać na oryginalnym interfejsie API w celu zapewnienia tożsamości użytkownika w inny sposób. Interfejs API podrzędny może niepoprawnie użyć uprawnienia aplikacji do wykonania operacji. Następnie oryginalny interfejs API stanie się jedynym organem, w którym użytkownicy mogą osiągnąć wyniki względem interfejsu API podrzędnego. Oryginalny interfejs API może celowo (lub przypadkowo) umożliwić użytkownikowi wykonanie zadania, którego użytkownik nie mógł wykonać w inny sposób. Na przykład jeden użytkownik może zmienić szczegóły innego użytkownika lub przeczytać i zaktualizować dokumenty, do których użytkownik nie ma uprawnień dostępu. Nieprawidłowa walidacja może powodować poważne problemy z zabezpieczeniami.
Aby uzyskać lepsze zabezpieczenia, oryginalny interfejs API uzyskuje delegowany token dostępu uprawnień w celu udostępnienia interfejsu API podrzędnego, gdy oryginalny interfejs API wykonuje wywołanie. Przyjrzyjmy się temu, jak to działa.
Aplikacja kliencka uzyskuje token dostępu w celu wywołania oryginalnego interfejsu API
Na poniższym diagramie przedstawiono aplikację klienta i oryginalny interfejs API.
Aplikacja kliencka uzyskała delegowany token dostępu uprawnień (wskazywany przez kształt pentagonu z etykietą "A") do oryginalnego interfejsu API. Delegowany token dostępu uprawnień umożliwia mu pracę w imieniu użytkownika w celu wywołania oryginalnego interfejsu API wymagającego autoryzacji.
Aplikacja kliencka zapewnia token dostępu oryginalnemu interfejsowi API
Poniższa animacja przedstawia aplikację kliencą dającą token dostępu oryginalnemu interfejsowi API. Oryginalny interfejs API w pełni weryfikuje i sprawdza token dostępu w celu określenia tożsamości użytkownika aplikacji klienckiej.
Oryginalny interfejs API przeprowadza walidację tokenu i wymuszanie
Następna animacja pokazuje, że po podaniu tokenu dostępu aplikacji klienckiej do oryginalnego interfejsu API oryginalny interfejs API wykonuje walidację tokenu i wymuszanie. Jeśli wszystko jest dobre, interfejs API kontynuuje i obsługuje żądanie aplikacji klienckiej.
Oryginalny interfejs API nie może używać tokenu dostępu do wywoływania interfejsu API podrzędnego
Poniższa animacja pokazuje, że oryginalny interfejs API chce teraz wywołać interfejs API podrzędny. Jednak oryginalny interfejs API nie może użyć tokenu dostępu do wywołania interfejsu API podrzędnego.
Oryginalny interfejs API wraca do identyfikatora Entra firmy Microsoft
W poniższej animacji oryginalny interfejs API musi wrócić do identyfikatora Entra firmy Microsoft. Wymaga tokenu dostępu w celu wywołania interfejsu API podrzędnego w imieniu użytkownika.
Następna animacja przedstawia oryginalny interfejs API dostarczający token, który oryginalny interfejs API otrzymał od aplikacji klienckiej i poświadczeń klienta oryginalnego interfejsu API.
Identyfikator Entra firmy Microsoft sprawdza, czy nie ma zgody, czy wymuszania dostępu warunkowego. Być może trzeba będzie wrócić do klienta wywołującego i podać przyczynę braku możliwości uzyskania tokenu. Zazwyczaj należy użyć procesu żądania oświadczeń, aby wrócić do aplikacji wywołującej z informacjami dotyczącymi braku zgody (na przykład związanych z zasadami dostępu warunkowego).
Identyfikator Entra firmy Microsoft wykonuje kontrole
W poniższej animacji identyfikator Entra firmy Microsoft wykonuje testy. Jeśli wszystko jest w porządku, identyfikator Entra firmy Microsoft wystawia token dostępu do oryginalnego interfejsu API w celu wywołania interfejsu API podrzędnego w imieniu użytkownika.
Oryginalny interfejs API ma kontekst użytkownika z przepływem On-Behalf-Of
Poniższa animacja ilustruje proces przepływu On-Behalf-Of ( OBO), który umożliwia interfejsowi API kontynuowanie kontekstu użytkownika podczas wywoływanego interfejsu API podrzędnego.
Oryginalne wywołania interfejsu API podrzędnego interfejsu API
W następnej animacji wywołujemy interfejs API podrzędny. Token odbierany przez interfejs API podrzędnego ma odpowiednie oświadczenie odbiorców (aud), które wskazuje interfejs API podrzędnego.
Token zawiera zakresy udzielonej zgody i oryginalną tożsamość użytkownika aplikacji. Interfejs API podrzędny może prawidłowo zaimplementować skuteczne uprawnienia, aby upewnić się, że zidentyfikowany użytkownik ma uprawnienia do wykonania żądanego zadania. Chcesz użyć elementu w imieniu przepływu, aby uzyskać tokeny dla interfejsu API w celu wywołania innego interfejsu API, aby upewnić się, że kontekst użytkownika przechodzi do wszystkich podrzędnych interfejsów API.
Najlepsza opcja: Oryginalny interfejs API wykonuje przepływ On-Behalf-Of
Ta ostatnia animacja pokazuje, że najlepszą opcją jest oryginalny interfejs API do wykonania przepływu On-Behalf-Of (OBO). Jeśli interfejs API podrzędny odbiera prawidłowy token, może poprawnie odpowiedzieć.
Gdy interfejs API działa w imieniu użytkownika i musi wywołać inny interfejs API, interfejs API musi używać OBO do uzyskania delegowanego tokenu dostępu uprawnień w celu wywołania interfejsu API podrzędnego w imieniu użytkownika. Interfejsy API nigdy nie powinny używać uprawnień aplikacji do wywoływania podrzędnych interfejsów API, gdy interfejs API działa w imieniu użytkownika.
Następne kroki
- Platforma tożsamości Microsoft przepływy uwierzytelniania i scenariusze aplikacji opisują przepływy uwierzytelniania i scenariusze aplikacji, w których są używane.
- Usługa API Protection opisuje najlepsze rozwiązania dotyczące ochrony interfejsu API za pośrednictwem rejestracji, definiowania uprawnień i zgody oraz wymuszania dostępu w celu osiągnięcia celów zero trust.
- Przykład interfejsu API chronionego przez platformę wyrażania zgody na tożsamość firmy Microsoft ułatwia projektowanie strategii uprawnień aplikacji o najniższych uprawnieniach w celu uzyskania najlepszego środowiska użytkownika.
- Dostosowywanie tokenów opisuje informacje, które można otrzymywać w tokenach firmy Microsoft Entra. Wyjaśniono w nim, jak dostosować tokeny w celu zwiększenia elastyczności i kontroli przy jednoczesnym zwiększeniu poziomu zabezpieczeń zerowego zaufania aplikacji z najmniejszymi uprawnieniami.
- W module Secure custom APIs with Microsoft Identity Learn (Zabezpieczanie niestandardowych interfejsów API przy użyciu tożsamości microsoft) wyjaśniono, jak zabezpieczyć internetowy interfejs API przy użyciu tożsamości firmy Microsoft i jak wywoływać go z innej aplikacji.
- Najlepsze rozwiązania dotyczące zabezpieczeń właściwości aplikacji opisują identyfikator URI przekierowania, tokeny dostępu (używane w przypadku przepływów niejawnych), certyfikaty i wpisy tajne, identyfikator URI identyfikatora aplikacji i własność aplikacji.
- Platforma tożsamości Microsoft biblioteki uwierzytelniania opisują obsługę bibliotek uwierzytelniania firmy Microsoft dla różnych typów aplikacji.