Authentifizieren von JavaScript-Apps für Azure-Dienste mithilfe des Azure SDK für JavaScript

Wenn eine Anwendung auf eine Azure-Ressource (z. B. Speicher, Schlüsseltresor oder kognitive Dienste) zugreifen muss, muss die Anwendung bei Azure authentifiziert werden. Dies gilt für alle Anwendungen, unabhängig davon, ob sie in Azure bereitgestellt, lokal bereitgestellt oder auf einer lokalen Entwicklerarbeitsstation entwickelt werden. In diesem Artikel werden die empfohlenen Ansätze zum Authentifizieren einer App bei Azure bei Verwendung des Azure SDK für JavaScript beschrieben.

Empfohlener App-Authentifizierungsansatz

Der empfohlene Prozess besteht darin, dass Ihre Apps die tokenbasierte Authentifizierung anstelle von Verbindungszeichenfolge oder Schlüsseln verwenden, wenn Sie azure-Ressourcen authentifizieren. Das Azure SDK bietet tokenbasierte Authentifizierung und ermöglicht Apps die nahtlose Authentifizierung bei Azure-Ressourcen, unabhängig davon, ob sich die App in der lokalen Entwicklung befindet, in Azure bereitgestellt oder auf einem lokalen Server bereitgestellt wird.

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 und wie im folgenden Diagramm dargestellt wird.

Environment	Authentifizierung
Lokal	Wenn ein Entwickler während der lokalen Entwicklung eine App ausführt: Die App kann sich entweder mit einem Anwendungsdienstprinzipal für die lokale Entwicklung oder mithilfe der Azure-Anmeldeinformationen des Entwicklers bei Azure authentifizieren. Jede dieser Optionen wird im Abschnitt Authentifizierung während der lokalen Entwicklung ausführlicher erläutert.
Azure	Wenn eine App in Azure gehostet wird: Die App sollte sich mit einer verwalteten Identität bei Azure-Ressourcen authentifizieren. Diese Option wird weiter unten im Abschnitt Authentifizierung in Serverumgebungen ausführlicher erläutert.
Lokal	Wenn eine App lokal gehostet und bereitgestellt wird: Die App sollte sich mithilfe eines Anwendungsdienstprinzipals bei Azure-Ressourcen authentifizieren. Diese Option wird weiter unten im Abschnitt Authentifizierung in Serverumgebungen ausführlicher erläutert.

Vorteile der tokenbasierten Authentifizierung

Beim Erstellen von Apps für Azure wird die tokenbasierte Authentifizierung über geheime Schlüssel (Verbindungszeichenfolge oder Schlüssel) dringend empfohlen. Die tokenbasierte Authentifizierung wird mit DefaultAzureCredential bereitgestellt.

Tokenbasierte Authentifizierung	Geheime Schlüssel (Verbindungszeichenfolge und Schlüssel)
Prinzip der geringsten Berechtigung, richten Sie die spezifischen Berechtigungen ein, die von der App für die Azure-Ressource benötigt werden.	Ein Verbindungszeichenfolge oder Schlüssel gewährt der Azure-Ressource volle Rechte.
Es ist kein Anwendungsgeheimnis zum Speichern vorhanden.	Muss geheime Schlüssel in der App-Einstellung oder Umgebungsvariable speichern und drehen.
Das Azure Identity SDK verwaltet Token für Sie im Hintergrund. Dies erleichtert die Verwendung der tokenbasierten Authentifizierung als Verbindungszeichenfolge.	Geheime Schlüssel werden nicht verwaltet.

Die Verwendung von Verbindungszeichenfolgen sollte auf erste Proof-of-Concept-Apps oder Entwicklungsprototypen beschränkt werden, die nicht auf Produktionsdaten oder vertrauliche Daten zugreifen. In allen anderen Fällen sollten Sie immer die tokenbasierten Authentifizierungsklassen, die im Azure SDK verfügbar sind, für die Authentifizierung bei Azure-Ressourcen verwenden.

Verwenden Sie das folgende SDK:

• @azure/identity

DefaultAzureCredential

Mit der Azure SDK DefaultAzureCredential-Methode können Apps je nach Umgebung, in der sie ausgeführt werden, unterschiedliche Authentifizierungsmethoden verwenden. Auf diese Weise können Apps ohne Codeänderungen in lokalen, Test- und Produktionsumgebungen bereitgestellt werden. Sie konfigurieren die entsprechende Authentifizierungsmethode für jede Umgebung und DefaultAzureCredential erkennen und verwenden diese Authentifizierungsmethode automatisch. Die Verwendung wird DefaultAzureCredential bevorzugt, um bedingte Logik oder Featurekennzeichnungen manuell zu codieren, um unterschiedliche Authentifizierungsmethoden in verschiedenen Umgebungen zu verwenden.

Details zur Verwendung der DefaultAzureCredential-Klasse finden Sie weiter unten in diesem Artikel im Abschnitt Verwenden von DefaultAzureCredential in einer Anwendung.

Authentifizierung in Serverumgebungen

Beim Hosten in einer Serverumgebung sollte jeder Anwendung eine eindeutige Anwendungsidentität pro Umgebung zugewiesen werden. In Azure wird eine App-Identität durch einen Dienstprinzipal dargestellt, einen speziellen Typ von Sicherheitsprinzipal, der zum Identifizieren und Authentifizieren von Apps bei Azure bestimmt ist. Welcher Dienstprinzipaltyp für Ihre App verwendet werden soll, hängt davon ab, wo Ihre App ausgeführt wird.

Authentifizierung während der lokalen Entwicklung

Wenn eine Anwendung während der lokalen Entwicklung auf der Arbeitsstation eines Entwicklers ausgeführt wird, muss sich die lokale Umgebung bei allen von der App verwendeten Azure-Diensten authentifizieren.

Verwenden von DefaultAzureCredential in einer Anwendung

Wenn Sie DefaultAzureCredential in einer JavaScript-App verwenden möchten, fügen Sie der Anwendung das @azure-/Identitätspaket hinzu.

npm install @azure/identity

Im folgenden Codebeispiel wird gezeigt, wie ein DefaultAzureCredential Objekt instanziieren und mit einer Azure SDK-Clientklasse verwendet wird. In diesem Fall verwendet ein BlobServiceClient für den Zugriff auf Blob Storage.

// connect-with-default-azure-credential.js
import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config'

const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');

const blobServiceClient = new BlobServiceClient(
  `https://${accountName}.blob.core.windows.net`,
  new DefaultAzureCredential()
);

DefaultAzureCredential erkennt automatisch den für die App konfigurierten Authentifizierungsmechanismus und ruft die erforderlichen Token ab, um die App bei Azure zu authentifizieren. Wenn eine Anwendung mehrere SDK-Clients verwendet, kann dasselbe Anmeldeinformationsobjekt mit jedem SDK-Clientobjekt verwendet werden.

Sequenz der Auswahl von Authentifizierungsmethoden bei Verwendung von DefaultAzureCredential

DefaultAzureCredential Implementiert intern eine Kette der Auswahl von Anmeldeinformationsanbietern für die Authentifizierung von Anwendungen für Azure-Ressourcen. Jeder Anmeldeinformationsanbieter kann erkennen, ob Anmeldeinformationen dieses Typs für die App konfiguriert sind. DefaultAzureCredential überprüft der Reihe nach jeden Anbieter und verwendet die Anmeldeinformationen des ersten Anbieters, der Anmeldeinformationen konfiguriert hat.

Wenn Sie mehrere Anmeldeinformationen konfiguriert haben, ist die Reihenfolge der Suche nach Anmeldeinformationen über die Kette wichtig.

Die Reihenfolge, in der nach Anmeldeinformationen für JavaScript gesucht wird, DefaultAzureCredential wird im Diagramm und in der folgenden Tabelle gezeigt.

Es gibt zwei Pfade:

• Bereitgestellter Dienst (Azure oder lokal): Die Sequenz beginnt mit den Umgebungsvariablen, dann mit der verwalteten Identität und den restlichen Speicherorten für anmeldeinformationen (Visual Studio Code, Azure CLI, Azure PowerShell).
• Lokale Umgebung des Entwicklers: Die Kette der lokalen Entwicklerarbeitsstation beginnt mit dem angemeldeten Visual Studio Code-Benutzer, der in der unteren Leiste der IDE angezeigt wird, und wechselt dann zur Azure CLI und dann zu Azure PowerShell. Es ist wichtig zu verstehen, ob Sie Ihre lokalen Umgebungsvariablen konfiguriert haben, entweder für Ihre gesamte Umgebung oder die virtuelle Umgebung eines Projekts (z. B. mit DOTENV), diese Variablen überschreiben die Visual Studio Code -> Azure CLI -> PowerShell-Kette, da sie die erste in der Kette eingecheckte Anmeldeinformationen sind.

Anmeldeinformationstyp	Beschreibung
Umgebung	DefaultAzureCredential liest eine Reihe von Umgebungsvariablen, um zu ermitteln, ob ein Anwendungsdienstprinzipal (Anwendungsbenutzer) für die App festgelegt wurde. Wenn ja, verwendet DefaultAzureCredential diese Werte, um die App bei Azure zu authentifizieren. Diese Methode wird am häufigsten in Serverumgebungen verwendet, kann aber auch bei der lokalen Entwicklung verwendet werden.
Verwaltete Identität	Wenn die Anwendung auf einem Azure-Host mit aktivierter verwalteter Identität bereitgestellt wird, authentifiziert DefaultAzureCredential die App mit dieser verwalteten Identität bei Azure. Die Authentifizierung mithilfe einer verwalteten Identität wird im Abschnitt Authentifizierung in Serverumgebungen dieses Dokuments erläutert. Diese Methode ist nur verfügbar, wenn eine Anwendung in Azure mithilfe eines dienstfähigen Diensts mit verwalteter Identität gehostet wird.
Visual Studio Code	Wenn sich der Entwickler mit dem Visual Studio Code-Azure-Konto-Plug-In bei Azure authentifiziert hat, authentifiziert DefaultAzureCredential die App mit demselben Konto bei Azure.
Azure CLI	Wenn sich ein Entwickler mit dem az login-Befehl in der Azure CLI bei Azure authentifiziert hat, authentifiziert DefaultAzureCredential die App mit demselben Konto bei Azure.
Azure PowerShell	Wenn sich ein Entwickler mit dem Connect-AzAccount-Cmdlet von Azure PowerShell bei Azure authentifiziert hat, authentifiziert DefaultAzureCredential die App mit demselben Konto bei Azure.
Interactive	Wenn diese Option aktiviert ist, authentifiziert DefaultAzureCredential den Entwickler interaktiv über den Standardbrowser des aktuellen Systems. Diese Option ist standardmäßig deaktiviert.