Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Apps können die Azure Identitätsbibliothek verwenden, um sich bei Microsoft Entra ID zu authentifizieren, wodurch die Apps auf Azure Dienste und Ressourcen zugreifen können. Diese Authentifizierungsanforderung gilt, ob die App für Azure, lokal gehostet oder lokal auf einer Entwicklerarbeitsstation ausgeführt wird. In diesem Artikel werden die empfohlenen Vorgehensweisen zum Authentifizieren einer App für Microsoft Entra ID in verschiedenen Umgebungen bei Verwendung der Azure SDK Clientbibliotheken beschrieben.
Empfohlener Ansatz für die App-Authentifizierung
Tokenbasierte Authentifizierung über Microsoft Entra ID ist der empfohlene Ansatz für die Authentifizierung von Apps für Azure, anstatt Verbindungszeichenfolgen oder schlüsselbasierte Optionen zu verwenden. Die Azure Identity library stellt Klassen bereit, die die tokenbasierte Authentifizierung unterstützen und Apps die Authentifizierung bei Azure Ressourcen ermöglichen, unabhängig davon, ob die App lokal, auf Azure oder auf einem lokalen Server ausgeführt wird.
Vorteile der tokenbasierten Authentifizierung
Die tokenbasierte Authentifizierung bietet die folgenden Vorteile gegenüber Verbindungszeichenfolgen:
- Die tokenbasierte Authentifizierung stellt sicher, dass nur die speziellen Apps, die auf die Azure Ressource zugreifen sollen, darauf zugreifen können, während jede App mit einem connection string eine Verbindung mit einer Azure Ressource herstellen kann.
- Die tokenbasierte Authentifizierung ermöglicht es Ihnen, Azure Ressourcenzugriff nur auf die spezifischen Berechtigungen zu beschränken, die von der App benötigt werden. Dieser Ansatz folgt dem Prinzip der geringsten Rechte. Im Gegensatz dazu gewährt ein connection string volle Rechte an der Azure Ressource.
- Wenn Sie eine managed Identity für die tokenbasierte Authentifizierung verwenden, verarbeitet Azure Administrative Funktionen für Sie, sodass Sie sich keine Gedanken über Aufgaben wie das Sichern oder Drehen von Geheimschlüsseln machen müssen. Mit diesem Ansatz wird die App sicherer, da keine connection string oder kein geheimer Anwendungsschlüssel vorhanden ist, der kompromittiert werden kann.
- Die Azure Identitätsbibliothek erwirbt und verwaltet Microsoft Entra Token für Sie.
Beschränken Sie die Verwendung von Verbindungszeichenfolgen auf Szenarien, in denen die tokenbasierte Authentifizierung keine Option, anfängliche Proof-of-Concept-Apps oder Entwicklungsprototypen ist, die nicht auf Produktionsdaten oder vertrauliche Daten zugreifen. Verwenden Sie nach Möglichkeit die tokenbasierten Authentifizierungsklassen in der Azure Identitätsbibliothek, um sich bei Azure Ressourcen zu authentifizieren.
Authentifizierung in verschiedenen Umgebungen
Die spezifische Art der tokenbasierten Authentifizierung, die eine App für die Authentifizierung bei Azure Ressourcen verwenden soll, hängt davon ab, wo die App ausgeführt wird. Das folgende Diagramm enthält Anleitungen für verschiedene Szenarien und Umgebungen:
Wenn eine App Folgendes tut:
- Hosted on Azure: Die App sollte sich bei Azure Ressourcen mithilfe einer verwalteten Identität authentifizieren. Weitere Informationen finden Sie im Abschnitt Authentication für Azure gehostete Apps.
- Lokal während der Entwicklung ausführen: Die App kann sich bei Azure mithilfe eines Entwicklerkontos authentifizieren, eines Brokers oder eines Service Principals. Weitere Informationen finden Sie im Abschnitt " Authentifizierung während der lokalen Entwicklung ".
- Hosted lokal: Die App sollte sich bei Azure-Ressourcen mithilfe eines Anwendungsdienstprinzipals oder einer verwalteten Identität bei Azure Arc authentifizieren. Lokale Workflows werden unter Authentifizierung für lokal gehostete Apps ausführlicher erläutert.
Authentifizierung für Azure gehostete Apps
Wenn Sie Ihre App auf Azure hosten, kann sie verwaltete Identitäten verwenden, um sich bei Azure Ressourcen zu authentifizieren, ohne Anmeldeinformationen verwalten zu müssen. Es stehen zwei Arten von verwalteten Identitäten zur Verfügung: vom Benutzer zugewiesen und vom System zugewiesen.
Verwenden einer benutzerseitig zugewiesenen verwalteten Identität
Sie können eine vom Benutzer zugewiesene verwaltete Identität als eigenständige Azure Ressource erstellen. Sie können sie dann einer oder mehreren Azure Ressourcen zuweisen, damit diese Ressourcen dieselbe Identität und Berechtigungen gemeinsam nutzen können. Um sich mithilfe einer vom Benutzer zugewiesenen verwalteten Identität zu authentifizieren, erstellen Sie die Identität, weisen Sie sie Ihrer Azure-Ressource zu, und konfigurieren Sie ihre App dann so, dass diese Identität für die Authentifizierung verwendet wird, indem Sie ihre Client-ID, Ressourcen-ID oder Objekt-ID angeben.
Verwenden einer systemseitig zugewiesenen verwalteten Identität
Sie können eine vom System zugewiesene verwaltete Identität direkt in einer Azure Ressource aktivieren. Die Identität ist an den Lebenszyklus dieser Ressource gebunden und wird automatisch gelöscht, wenn die Ressource gelöscht wird. Um sich mithilfe einer vom System zugewiesenen verwalteten Identität zu authentifizieren, aktivieren Sie die Identität in Ihrer Azure Ressource, und konfigurieren Sie Ihre App dann so, dass diese Identität für die Authentifizierung verwendet wird.
Authentifizierung während der lokalen Entwicklung
Während der lokalen Entwicklung können Sie sich bei Azure-Ressourcen authentifizieren, indem Sie Ihre Entwickleranmeldeinformationen, einen Broker oder einen Dienstprinzipal verwenden. Mithilfe einer dieser Methoden können Sie die Authentifizierungslogik Ihrer App testen, ohne sie für Azure bereitzustellen.
Verwenden Sie Entwickleranmeldeinformationen
Sie können Ihre eigenen Azure Anmeldeinformationen verwenden, um sich während der lokalen Entwicklung bei Azure Ressourcen zu authentifizieren. In der Regel verwenden Sie ein Entwicklungstool wie Azure CLI, Azure Developer CLI, Azure PowerShell, Visual Studio Code oder IntelliJ IDEA. Diese Tools können Ihrer App die erforderlichen Token für den Zugriff auf Azure Dienste bereitstellen. Diese Methode ist praktisch, aber Sie sollten sie nur für Entwicklungszwecke verwenden.
Verwenden eines Brokers
Die vermittelte Authentifizierung sammelt Benutzeranmeldeinformationen mithilfe des Systemauthentifizierungsbrokers, um eine App zu authentifizieren. Ein Systemauthentifizierungsbroker wird auf dem Computer eines Benutzers ausgeführt und verwaltet die Authentifizierungs-Handshakes und die Tokenwartung für alle verbundenen Konten.
Verwenden eines Dienstprinzipals
Sie können einen Dienstprinzipal in einem Microsoft Entra Mandanten erstellen, um eine App darzustellen und sich bei Azure Ressourcen zu authentifizieren. Sie können Ihre App so konfigurieren, dass sie während der lokalen Entwicklung Anmeldeinformationen für das Dienstprinzipal verwendet. Diese Methode ist sicherer als die Verwendung von Entwickleranmeldeinformationen und ist näher an der Authentifizierung Ihrer App in der Produktion. Es ist jedoch immer noch weniger ideal als die Verwendung einer verwalteten Identität aufgrund der Notwendigkeit geheimer Schlüssel.
Authentifizierung für lokal gehostete Apps
Um sich bei Azure-Ressourcen zu authentifizieren, können Sie für lokal gehostete Apps einen Dienstprinzipal verwenden. Dazu gehört das Erstellen eines Dienstprinzipals in Microsoft Entra ID, das Zuweisen der erforderlichen Berechtigungen und das Konfigurieren der App für die Verwendung seiner Anmeldeinformationen. Mit dieser Methode kann Ihre lokale App sicher auf Azure Dienste zugreifen.