Szenario: Daemon-App zum Aufrufen von Web-APIs

Erfahren Sie alles über die Erstellung einer Daemonanwendung, 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

Beispiele für Anwendungsfälle für Daemon-Apps:

  • 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äufig vorkommenden Fall, bei dem Nicht-Daemonanwendungen Clientanmeldeinformationen verwenden: Auch wenn sie im Auftrag von Benutzern fungieren, müssen sie aus technischen Gründen unter ihrer eigenen Identität auf eine Web-API oder eine Ressource zugreifen. Ein Beispiel ist der Zugriff auf Geheimnisse in Azure Key Vault oder auf Azure SQL-Datenbank für einen Cache.

Hinweis

Sie können keine Daemonanwendung auf dem Gerät eines normalen Benutzers bereitstellen, und ein normaler Benutzer kann nicht auf eine Daemonanwendung zugreifen. Nur eine begrenzte Gruppe von IT-Administratoren kann auf Geräte zugreifen, auf denen Daemonanwendungen ausgeführt werden. Daher kann ein fehlerhafter Akteur nicht auf einen geheimen Clientschlüssel oder ein Token aus dem Gerätedatenverkehr zugreifen und im Auftrag der Daemonanwendung agieren. 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:

  • Sie sind vertrauliche Clientanwendungen. Diese Apps müssen angesichts der Tatsache, dass sie unabhängig von Benutzern auf Ressourcen zugreifen, ihre Identität nachweisen. Sie sind außerdem eher sensible Apps. Sie müssen von den Azure Active Directory (Azure AD)-Mandantenadministratoren genehmigt werden.
  • Sie haben bei Azure AD ein Geheimnis registriert (Anwendungskennwort oder Zertifikat). Dieses Geheimnis wird während des Aufrufs an Azure AD zum Abrufen eines Tokens übergeben.

Besonderheiten

Benutzer können nicht mit einer Daemonanwendung in Interaktion treten. Eine Daemonanwendung erfordert eine eigene Identität. Diese Art von Anwendung fordert auf der Grundlage ihrer Anwendungsidentität ein Zugriffstoken an und gibt dabei gegenüber Azure AD 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 Azure AD-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 Azure AD 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 Azure AD 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.