Szenario: Daemon-App zum Aufrufen von Web-APIs

In diesem Szenario wird das Erstellen einer Daemonanwendung behandelt, die Web-APIs aufruft.

Übersicht

Ihre Anwendung kann ein Token abrufen, um eine Web-API im eigenen Namen (nicht im Namen eines Benutzers) aufzurufen. Dieses Szenario eignet sich für Daemonanwendungen. Es verwendet die Standardzuweisung für Clientanmeldeinformationen von OAuth 2.0.

Daemon apps

Einige Anwendungsfallbeispiele für Daemon-Apps sind:

  • Webanwendungen zum Bereitstellen oder Verwalten von Benutzern oder für Batchprozesse in einem Verzeichnis
  • Desktopanwendungen (z. B. Windows-Dienste unter Windows oder Daemonprozesse unter Linux), die Batchaufträge ausführen, oder ein Betriebssystemdienst, der im Hintergrund ausgeführt wird
  • Web-APIs, die Verzeichnisse und keine bestimmten Benutzer bearbeiten müssen

Es gibt einen weiteren häufigen Fall, in dem Nicht-Daemonanwendungen Clientanmeldeinformationen verwenden, auch wenn sie im Namen von Benutzern handeln. Dies passiert, wenn sie aus technischen Gründen auf eine Web-API oder eine Ressource unter ihrer eigenen Identität zugreifen müssen. Ein Beispiel ist der Zugriff auf Geheimnisse in Azure Key Vault oder auf Azure SQL-Datenbank für einen Cache.

Sie können keine Daemonanwendung auf dem Gerät eines normalen Benutzers bereitstellen, und ein normaler Benutzer kann nicht auf eine Daemonanwendung zugreifen. Auf Geräte, auf denen Daemonanwendungen ausgeführt werden, können nur bestimmte IT-Administratoren zugreifen. Der Grund dafür ist, zu verhindern, dass ein böswilliger Akteur auf einen geheimen Clientschlüssel oder ein Token im Datenverkehr des Geräts zugreifen und im Namen der Daemonanwendung handeln kann. Das Daemonanwendungsszenario ersetzt nicht die Geräteauthentifizierung.

Beispiele für Nicht-Daemonanwendungen:

  • Eine mobile Anwendung, die im Auftrag einer Anwendung, aber nicht im Auftrag eines Benutzers auf einen Webdienst zugreift.
  • Eine IoT-Gerät, das im Auftrag eines Geräts, aber nicht im Auftrag eines Benutzers auf einen Webdienst zugreift.

Für Anwendungen, die ein Token für ihre eigenen Identitäten abrufen, gilt Folgendes:

  • Vertrauliche Clientanwendungen müssen angesichts der Tatsache, dass sie unabhängig von Benutzern auf Ressourcen zugreifen, ihre Identität nachweisen. Microsoft Entra-Mandantenadministratoren müssen diesen eher sensiblen Apps Genehmigung erteilen.
  • Sie haben bei Microsoft Entra ID ein Geheimnis registriert (Anwendungskennwort oder Zertifikat). Dieses Geheimnis wird während des Aufrufs an Microsoft Entra ID zum Abrufen eines Tokens übergeben.

Besonderheiten

Eine Interaktion von Benutzern mit einer Daemonanwendung ist nicht möglich, da die Daemonanwendung eine eigene Identität benötigt. Diese Art von Anwendung fordert auf der Grundlage ihrer Anwendungsidentität ein Zugriffstoken an und gibt dabei gegenüber Microsoft Entra ID ihre Anwendungs-ID, ihre Anmeldeinformationen (Kennwort oder Zertifikat) sowie ihren Anwendungs-ID-URI an. Nach erfolgreicher Authentifizierung erhält der Daemon von Microsoft Identity Platform ein Zugriffstoken (und ein Aktualisierungstoken). Dieses Token wird dann zum Aufrufen der Web-API verwendet (und nach Bedarf aktualisiert).

Da Benutzer nicht mit Daemonanwendungen interagieren können, ist keine inkrementelle Zustimmung möglich. Alle erforderlichen API-Berechtigungen müssen bei der Anwendungsregistrierung konfiguriert werden. Der Anwendungscode fordert nur statisch definierte Berechtigungen an. Dies bedeutet auch, dass Daemonanwendungen die inkrementelle Einwilligung nicht unterstützen.

Für Entwickler umfasst die End-to-End-Umgebung für dieses Szenario die folgenden Aspekte:

  • Daemonanwendungen funktionieren nur in Microsoft Entra-Mandanten. Es wäre nicht sinnvoll, eine Daemonanwendung zu erstellen, die persönliche Microsoft-Konten zu bearbeiten versucht. Wenn Sie Entwickler für eine branchenspezifische App sind, erstellen Sie Ihre Daemon-App in Ihrem Mandanten. Wenn Sie ein ISV sind, empfiehlt sich die Erstellung einer mehrinstanzenfähigen Daemonanwendung. Jeder Mandantenadministrator muss seine Zustimmung geben.
  • Bei der Anwendungsregistrierung ist der Antwort-URI nicht erforderlich. Geben Sie Geheimnisse oder Zertifikate bzw. signierte Assertionen für Microsoft Entra ID frei. Sie müssen auch Anwendungsberechtigungen anfordern und Administratorzustimmung erteilen, um diese App-Berechtigungen zu verwenden.
  • Die Anwendungskonfiguration muss die Clientanmeldeinformationen bereitstellen, die bei der Anwendungsregistrierung für Microsoft Entra ID freigegeben wurden.
  • Der Bereich zum Abrufen eines Tokens über den Clientanmeldeinformations-Flow muss statisch sein.

Wenn Sie neu im Bereich Identitäts- und Zugriffsverwaltung (IAM) mit OAuth 2.0 und OpenID Connect sind oder auch nur neu im Bereich IAM auf der Microsoft Identity Platform, sollten die folgenden Artikel ganz oben auf Ihrer Leseliste stehen.

Obwohl es nicht erforderlich ist, sie vor dem Abschluss Ihres ersten Schnellstarts oder Tutorials zu lesen, decken sie Themen ab, die integraler Bestandteil der Plattform sind, und die Vertrautheit mit ihnen wird Ihnen auf Ihrem Weg beim Erstellen komplexerer Szenarien helfen.

Nächste Schritte

Fahren Sie mit dem nächsten Artikel in diesem Szenario fort: App-Registrierung.