Wywoływanie interfejsu API z innego interfejsu API

Jak, jako deweloper, zapewniasz Zero Trust, gdy jeden interfejs API musi wywołać inny interfejs API? Z tego artykułu dowiesz się, jak bezpiecznie opracowywać aplikację podczas jej pracy w imieniu użytkownika.

Gdy użytkownik obsługuje interfejs użytkownika aplikacji, aplikacja może używać delegowanego uprawnienia, aby interfejs API zrozumiał, na czyje konto aplikacja działa. Sprawdza on oświadczenie podmiotu (sub) lub identyfikator obiektu (oid) oraz oświadczenia identyfikatora dzierżawy (tid) w tokenie dostępu, który aplikacja udostępnia podczas wywoływania interfejsu API. Interfejs API nie opiera się na niezaufanej aplikacji, która jest tylko wywołaniem pochodzącym z sieci. Zamiast tego weryfikuje 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 interfejs API, który wywołujemy (nazywamy go interfejsem API podrzędnym), był zgodny z procesem weryfikacji. Interfejs API downstream nie może opierać się 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 staje się jedynym autorytetem, który decyduje, jacy użytkownicy mogą uzyskiwać określone wyniki w odniesieniu do interfejsu API podrzędnego. Oryginalny interfejs API może celowo (lub przypadkowo) umożliwić użytkownikowi wykonanie zadania, którego użytkownik nie może 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 token dostępu z delegowanymi uprawnieniami, aby udostępnić go interfejsowi API podrzędnemu, kiedy oryginalny interfejs API wykonuje to wywołanie. Przyjrzyjmy się temu, jak to działa.

1. Aplikacja kliencka uzyskuje token dostępu w celu wywołania oryginalnego interfejsu API. Aplikacja kliencka uzyskuje delegowany token dostępu uprawnień 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.
2. Aplikacja kliencka zapewnia token dostępu oryginalnemu interfejsowi API. Aplikacja kliencka udostępnia 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.
3. Oryginalny interfejs API przeprowadza walidację i wymuszanie tokenu. Po tym, jak aplikacja kliencka przekaże token dostępu do pierwotnego interfejsu API, pierwotny interfejs API wykonuje walidację tokenu i egzekwowanie. Jeśli wszystko jest w porządku, interfejs API przetwarza i obsługuje żądanie aplikacji klienckiej.
4. Oryginalny interfejs API nie może używać tokenu dostępu do wywoływania interfejsu API podrzędnego. Oryginalny interfejs API chce wywołać interfejs API podrzędnego. Jednak oryginalny interfejs API nie może użyć tokenu dostępu do wywołania interfejsu API podrzędnego.
5. Oryginalny interfejs API wraca do identyfikatora Entra firmy Microsoft. 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. Oryginalny interfejs API udostępnia token otrzymany z aplikacji klienckiej oraz poświadczenia klienta.
6. Identyfikator Entra firmy Microsoft wykonuje kontrole. Identyfikator Entra firmy Microsoft sprawdza takie kwestie, jak zgoda lub egzekwowanie 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). 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.
7. Oryginalny interfejs API ma kontekst użytkownika z przepływem On-Behalf-Of. Proces On- flowBehalf-Of (OBO) pozwala interfejsowi API zachować kontekst użytkownika podczas wywoływania podrzędnego interfejsu API.
8. Oryginalny interfejs API wywołuje interfejs API niższego poziomu. Wywołaj podrzędne API. 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ć przepływu 'działając w imieniu', aby uzyskać tokeny dla jednego interfejsu API, które pozwolą wywołać inny interfejs API i zapewnić, że kontekst użytkownika przechodzi do wszystkich docelowych interfejsów API.

Najlepsza opcja: Oryginalny interfejs API wykonuje przepływ typu On-Behalf-Of.

Oryginalne API powinno być wykonane w przepływie 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

• Przepływy uwierzytelniania i scenariusze aplikacji platformy tożsamości Microsoft opisują przepływy uwierzytelniania oraz 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 ramy zgody na tożsamość firmy Microsoft pomaga w projektowaniu strategii uprawnień aplikacji minimalnych, co zapewnia najlepsze doświadczenie 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ń Zero Trust aplikacji z najniższymi 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ć webowy interfejs API przy użyciu tożsamości firmy Microsoft i jak go wywołać z innej aplikacji.
• Najlepsze praktyki dotyczące zabezpieczeń właściwości aplikacji opisują identyfikator URI przekierowania, tokeny dostępu, certyfikaty i tajne klucze, identyfikator URI aplikacji oraz własność aplikacji.
• Biblioteki uwierzytelniania platformy tożsamości Microsoft opisuje obsługę Biblioteki uwierzytelniania Microsoft dla różnych typów aplikacji.