Freigeben über

Bewährte Methoden für die Authentifizierung mit der Azure Identity-Bibliothek für JavaScript

Dieser Artikel enthält Richtlinien, mit denen Sie die Leistung und Zuverlässigkeit Ihrer JavaScript- und TypeScript-Apps beim Authentifizieren bei Azure-Diensten maximieren können. Um die Azure Identity-Bibliothek für JavaScript optimal zu nutzen, ist es wichtig, potenzielle Probleme und Gegenmaßnahmen zu verstehen.

Verwenden Sie deterministische Anmeldeinformationen in Produktionsumgebungen

DefaultAzureCredential ist der benutzerfreundlichste Weg, um mit der Azure Identity-Bibliothek zu beginnen, aber diese Bequemlichkeit geht auch mit bestimmten Kompromissen einher. Vor allem die spezifischen Anmeldeinformationen in der Kette, die erfolgreich sind und für die Anforderungsauthentifizierung verwendet werden, können vorab nicht garantiert werden. In einer produktiven Umgebung kann diese Unvorhersehbarkeit zu erheblichen und manchmal subtilen Problemen führen.

Betrachten Sie zum Beispiel die folgende hypothetische Sequenz von Ereignissen:

  1. Das Sicherheitsteam einer Organisation schreibt vor, dass alle Apps eine verwaltete Identität verwenden, um sich bei Azure-Ressourcen zu authentifizieren.
  2. Monatelang verwendet DefaultAzureCredential eine javaScript-App, die auf einem virtuellen Azure-Computer (VM) gehostet wird, erfolgreich zur Authentifizierung über verwaltete Identität.
  3. Ohne das Support-Team zu informieren, installiert ein Entwickler das Azure CLI auf dieser VM und führt den az login Befehl aus, um sich bei Azure zu authentifizieren.
  4. Aufgrund dieser neuen separaten Konfigurationsänderung in der Azure-Umgebung fällt die Authentifizierung über die ursprüngliche verwaltete Identität unerwartet ohne erkennbare Anzeichen aus.
  5. DefaultAzureCredential überspringt die fehlgeschlagene ManagedIdentityCredential und sucht nach der nächsten verfügbaren Anmeldeinformation, die AzureCliCredential ist.
  6. Die Anwendung beginnt mit der Verwendung der Azure CLI-Anmeldeinformationen anstelle der verwalteten Identität, was möglicherweise fehlschlägt oder zu unerwarteten Erhöhungen und Reduzierungen von Berechtigungen führen kann.

Um diese Arten von subtilen Problemen oder stillen Fehlern in Produktionsanwendungen zu verhindern, ersetzen Sie DefaultAzureCredential durch eine spezifische TokenCredential Implementierung, z. B. ManagedIdentityCredential. In der Dokumentation zur Azure Identity-Clientbibliothek finden Sie verfügbare Anmeldeinformationen.

Betrachten Sie beispielsweise die folgende DefaultAzureCredential Konfiguration in einem Express.js Projekt:

import { DefaultAzureCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";
import { BlobServiceClient } from "@azure/storage-blob";

const credential = new DefaultAzureCredential();

const secretClient = new SecretClient("https://keyVaultName.vault.azure.net", credential);
const blobServiceClient = new BlobServiceClient(
  "https://storageAccountName.blob.core.windows.net",
  credential
);

Ändern Sie den vorherigen Code, um basierend auf der Umgebung, in der die App ausgeführt wird, anmeldeinformationen auszuwählen:

import { AzureDeveloperCliCredential, ManagedIdentityCredential, ChainedTokenCredential, 
         AzureCliCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";
import { BlobServiceClient } from "@azure/storage-blob";

let credential;

// In production, use only ManagedIdentityCredential
if (process.env.NODE_ENV === 'production') {
  // For user-assigned managed identity, provide the client ID
  credential = new ManagedIdentityCredential(process.env.AZURE_CLIENT_ID);
}
// In development, use a chain of credentials appropriate for local work
else {
  credential = new ChainedTokenCredential(
    new AzureCliCredential(),
    new AzureDeveloperCliCredential()
  );
}

// Initialize Key Vault client
const secretClient = new SecretClient("https://keyVaultName.vault.azure.net", credential);

// Initialize Blob Storage client
const blobServiceClient = new BlobServiceClient(
  "https://storageAccountName.blob.core.windows.net",
  credential
);

In diesem Beispiel wird nur ManagedIdentityCredential in der Produktion verwendet. Die Authentifizierungsanforderungen der lokalen Entwicklungsumgebung werden dann durch die Sequenz von Anmeldeinformationen, die in der else Klausel definiert sind, gewartet.

Wiederverwendung von Zugangsdateninstanzen

Verwenden Sie nach Möglichkeit Authentifizierungsinstanzen, um die Resilienz der App zu verbessern und die Anzahl der Zugriffstokenanforderungen zu verringern, die an Microsoft Entra ID ausgegeben werden. Wenn eine Anmeldeinformation wiederverwendet wird, wird versucht, ein Token aus dem App-Token-Cache zu holen, der von der zugrunde liegenden MSAL-Abhängigkeit verwaltet wird. Weitere Informationen finden Sie unter Token-Caching in der Azure Identity-Clientbibliothek.

Das Verhalten der Tokenzwischenspeicherung unterscheidet sich zwischen Browser- und Node.js-Umgebungen. In Node.js Anwendungen werden Token standardmäßig im Arbeitsspeicher zwischengespeichert, was bedeutet, dass der Cache verloren geht, wenn die Anwendung neu gestartet wird. In Browseranwendungen können Token je nach Authentifizierungsfluss und Konfiguration im Browserspeicher (localStorage oder sessionStorage) beibehalten werden. Das Verständnis dieser Unterschiede ist bei der Implementierung von Wiederverwendungsstrategien für Anmeldeinformationen für verschiedene Anwendungstypen wichtig.

Von Bedeutung

Eine hochfrequent genutzte App, die keine Anmeldeinformationen wiederverwendet, kann auf HTTP 429-Begrenzungsantworten von Microsoft Entra ID stoßen, was zu Anwendungsausfällen führen kann.

Die empfohlene Wiederverwendungsstrategie für Anmeldeinformationen unterscheidet sich vom Anwendungsframework.

Um die Wiederverwendung von Anmeldeinformationen in JavaScript-Anwendungen zu implementieren, erstellen Sie eine einzelne Anmeldeinformationsinstanz, und verwenden Sie sie für alle Clientobjekte wieder:

import { DefaultAzureCredential, ManagedIdentityCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";
import { BlobServiceClient } from "@azure/storage-blob";

// Create a single credential instance
const credential = process.env.NODE_ENV === 'production'
  ? new ManagedIdentityCredential(process.env.AZURE_CLIENT_ID)
  : new DefaultAzureCredential();

// Reuse the credential across different client objects
const secretClient = new SecretClient("https://keyVaultName.vault.azure.net", credential);
const blobServiceClient = new BlobServiceClient(
  "https://storageAccountName.blob.core.windows.net",
  credential
);

In Express.js Anwendungen können Sie die Anmeldeinformationen in den App-Einstellungen speichern und in Ihren Routenhandlern darauf zugreifen:

import express from "express";
import { DefaultAzureCredential, ManagedIdentityCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";
import { BlobServiceClient } from "@azure/storage-blob";

const app = express();

// Create a single credential instance at app startup
app.locals.credential = process.env.NODE_ENV === 'production'
  ? new ManagedIdentityCredential(process.env.AZURE_CLIENT_ID)
  : new DefaultAzureCredential();

// Reuse the credential in route handlers
app.get('/api/secrets/:secretName', async (req, res) => {
  const secretClient = new SecretClient(
    "https://keyVaultName.vault.azure.net", 
    req.app.locals.credential
  );
  
  try {
    const secret = await secretClient.getSecret(req.params.secretName);
    res.json({ name: secret.name, value: secret.value });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

// Add this route to the existing Express app
app.get('/api/blobs/:containerName', async (req, res) => {
  const blobServiceClient = new BlobServiceClient(
    "https://storageAccountName.blob.core.windows.net", 
    req.app.locals.credential
  );
  
  try {
    // Get reference to a container
    const containerClient = blobServiceClient.getContainerClient(req.params.containerName);
    
    // List all blobs in the container
    const blobs = [];
    for await (const blob of containerClient.listBlobsFlat()) {
      blobs.push({
        name: blob.name,
        contentType: blob.properties.contentType,
        size: blob.properties.contentLength,
        lastModified: blob.properties.lastModified
      });
    }
    
    res.json({ containerName: req.params.containerName, blobs });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

app.listen(3000, () => console.log('Server running on port 3000'));

Verstehen, wann Tokenlebensdauer und Zwischenspeicherungslogik erforderlich sind

Wenn Sie eine Azure Identity-Bibliotheksanmeldung außerhalb des Kontexts einer Azure SDK-Clientbibliothek verwenden, liegt die Verantwortung für die Verwaltung der Tokenlebensdauer und des Zwischenspeicherungsverhaltens in Ihrer App.

Die refreshAfterTimestamp Eigenschaft auf AccessToken, die Verbrauchern einen Hinweis gibt, wann die Tokenaktualisierung versucht werden kann, wird automatisch von Azure SDK-Clientbibliotheken verwendet, die von der Azure Core-Bibliothek abhängen, um das Token zu aktualisieren. Für die direkte Verwendung von Azure Identity-Bibliotheksanmeldeinformationen, die das Zwischenspeichern von Token unterstützen, wird der zugrunde liegende MSAL-Cache automatisch proaktiv aktualisiert, wenn die refreshAfterTimestamp Zeit eintritt. Dieser Entwurf ermöglicht es dem Clientcode, TokenCredential.getToken() jedes Mal aufzurufen, wenn ein Token benötigt wird, und die Aktualisierung an die Bibliothek delegieren.

Um TokenCredential.getToken() nur bei Bedarf aufzurufen, beobachten Sie das refreshAfterTimestamp Datum, und versuchen Sie proaktiv, das Token nach dieser Zeit zu aktualisieren. Die spezifische Implementierung liegt beim Kunden.

Verständnis der Wiederholungsstrategie für verwaltete Identitäten

Mit der Azure Identity-Bibliothek für JavaScript können Sie sich über verwaltete Identität authentifizieren mit ManagedIdentityCredential. Die Art und Weise, wie Sie ManagedIdentityCredential verwenden, wirkt sich auf die angewendete Wiederholungsstrategie aus.

  • Bei Verwendung über DefaultAzureCredentialwerden keine Wiederholungen versucht, wenn der anfängliche Tokenakquisitionsversuch nach kurzer Dauer fehlschlägt oder ausfällt. Dies ist die wenigst robuste Option, da sie so optimiert ist, dass sie möglichst schnell scheitert, um eine effiziente interne Entwicklungsschleife zu fördern.
  • Jeder andere Ansatz, z. B. ChainedTokenCredential oder ManagedIdentityCredential direkt:
    • Das Zeitintervall zwischen den Wiederholungsversuchen beginnt bei 0,8 Sekunden, und es werden standardmäßig maximal fünf Wiederholungsversuche unternommen. Diese Option ist für Resilienz optimiert, führt aber potenziell unerwünschte Verzögerungen in der inneren Schleife der Entwicklung ein.
    • Verwenden Sie die Eigenschaft "retryOptions " im Optionsparameter, um die Standardeinstellungen für wiederholungsversuche zu ändern. Versuchen Sie es zum Beispiel maximal dreimal mit einem Startintervall von 0,5 Sekunden:
import { ManagedIdentityCredential } from "@azure/identity";

const credential = new ManagedIdentityCredential(
  process.env.AZURE_CLIENT_ID, // For user-assigned managed identity
  {
    retryOptions: {
      maxRetries: 3,           // Maximum number of retry attempts
      retryDelayInMs: 500,     // Initial delay between retries (in milliseconds)
      maxRetryDelayInMs: 5000  // Maximum delay between retries (in milliseconds)
    }
  }
);

Weitere Informationen zum Anpassen von Wiederholungsrichtlinien für verwaltete Identitäten finden Sie unter einer der folgenden Optionen, die von TokenCredentialOptions erweitert werden: