Scenariusz: aplikacja demona, która wywołuje internetowe interfejsy API

  • Artykuł

Ten scenariusz przeprowadzi Cię przez proces tworzenia aplikacji demona, która wywołuje internetowe interfejsy API.

Omówienie

Aplikacja może uzyskać token w celu wywołania internetowego interfejsu API w imieniu samego siebie (nie w imieniu użytkownika). Ten scenariusz jest przydatny w przypadku aplikacji demona. Używa ona standardowego przyznawania poświadczeń klienta OAuth 2.0.

Daemon apps

Oto kilka przykładów przypadków użycia dla aplikacji demona;

  • Aplikacje internetowe używane do aprowizowania lub administrowania użytkownikami lub wykonywania procesów wsadowych w katalogu
  • Aplikacje klasyczne (takie jak usługi systemu Windows w systemie Windows lub procesy demona w systemie Linux), które wykonują zadania wsadowe lub usługę systemu operacyjnego działającą w tle
  • Internetowe interfejsy API, które muszą manipulować katalogami, a nie określonymi użytkownikami

Istnieje inny typowy przypadek, w którym aplikacje nienależące do demona używają poświadczeń klienta, nawet jeśli działają w imieniu użytkowników. Dzieje się tak, gdy muszą uzyskać dostęp do internetowego interfejsu API lub zasobu w ramach własnej tożsamości ze względów technicznych. Przykładem jest dostęp do wpisów tajnych w usłudze Azure Key Vault lub azure SQL Database dla pamięci podręcznej.

Nie można wdrożyć aplikacji demona na urządzeniu zwykłego użytkownika, a zwykły użytkownik nie może uzyskać dostępu do aplikacji demona. Tylko ograniczony zestaw administratorów IT może uzyskiwać dostęp do urządzeń z uruchomionymi aplikacjami demona. Jest to tak, że zły aktor nie może uzyskać dostępu do klucza tajnego klienta lub tokenu z ruchu urządzenia i działać w imieniu aplikacji demona. Scenariusz aplikacji demona nie zastępuje uwierzytelniania urządzenia.

Przykłady aplikacji innych niż demon:

  • Aplikacja mobilna, która uzyskuje dostęp do usługi internetowej w imieniu aplikacji, ale nie w imieniu użytkownika.
  • Urządzenie IoT, które uzyskuje dostęp do usługi internetowej w imieniu urządzenia, ale nie w imieniu użytkownika.

Aplikacje, które uzyskują token dla własnych tożsamości:

  • Poufne aplikacje klienckie, biorąc pod uwagę, że uzyskują dostęp do zasobów niezależnie od użytkowników, muszą potwierdzić swoją tożsamość. Administratorzy dzierżawy firmy Microsoft Entra muszą udzielić zatwierdzenia tym raczej poufnym aplikacjom.
  • Zarejestrowano wpis tajny (hasło aplikacji lub certyfikat) przy użyciu identyfikatora Entra firmy Microsoft. Ten wpis tajny jest przekazywany podczas wywołania do identyfikatora Entra firmy Microsoft w celu uzyskania tokenu.

Specyfiki

Użytkownicy nie mogą wchodzić w interakcje z aplikacją demona, ponieważ wymaga własnej tożsamości. Ten typ aplikacji żąda tokenu dostępu przy użyciu tożsamości aplikacji i prezentowania identyfikatora aplikacji, poświadczeń (hasła lub certyfikatu) oraz identyfikatora URI identyfikatora aplikacji do identyfikatora Entra firmy Microsoft. Po pomyślnym uwierzytelnieniu demon odbiera token dostępu (i token odświeżania) z Platforma tożsamości Microsoft. Ten token jest następnie używany do wywoływania internetowego interfejsu API (i jest odświeżany zgodnie z potrzebami).

Ponieważ użytkownicy nie mogą wchodzić w interakcje z aplikacjami demona, przyrostowa zgoda nie jest możliwa. Wszystkie wymagane uprawnienia interfejsu API należy skonfigurować podczas rejestracji aplikacji. Kod aplikacji żąda tylko statycznie zdefiniowanych uprawnień. Oznacza to również, że aplikacje demona nie będą obsługiwać przyrostowej zgody.

W przypadku deweloperów środowisko kompleksowe dla tego scenariusza ma następujące aspekty:

  • Aplikacje demona mogą działać tylko w dzierżawach firmy Microsoft Entra. Nie ma sensu tworzyć aplikacji demona, która próbuje manipulować kontami osobistymi Microsoft. Jeśli jesteś deweloperem aplikacji biznesowych (LOB), utworzysz aplikację demona w dzierżawie. Jeśli jesteś niezależnego dostawcą oprogramowania, możesz utworzyć wielodostępną aplikację demona. Każdy administrator dzierżawy musi wyrazić zgodę.
  • Podczas rejestracji aplikacji identyfikator URI odpowiedzi nie jest wymagany. Udostępnianie wpisów tajnych lub certyfikatów lub podpisanych asercji za pomocą identyfikatora Entra firmy Microsoft. Musisz również zażądać uprawnień aplikacji i udzielić zgody administratora na korzystanie z tych uprawnień aplikacji.
  • Konfiguracja aplikacji musi podać poświadczenia klienta jako udostępnione identyfikatorowi Microsoft Entra ID podczas rejestracji aplikacji.
  • Zakres używany do uzyskiwania tokenu przy użyciu przepływu poświadczeń klienta musi być zakresem statycznym.

Jeśli dopiero zaczynasz zarządzać tożsamościami i dostępem (IAM) przy użyciu protokołu OAuth 2.0 i openID Połączenie, a nawet dopiero zaczynasz korzystać z zarządzania dostępem i tożsamościami w Platforma tożsamości Microsoft, na liście do czytania powinny znajdować się następujące artykuły.

Mimo że nie jest to wymagane czytanie przed ukończeniem pierwszego przewodnika Szybki start lub samouczka, obejmują one tematy integralne dla platformy i znajomość z nimi ułatwią Ci drogę podczas tworzenia bardziej złożonych scenariuszy.

Uwierzytelnianie i autoryzacja

Platforma tożsamości Microsoft

Następne kroki

Przejdź do następnego artykułu w tym scenariuszu Rejestracja aplikacji.