Megosztás a következőn keresztül:

Ajánlott hitelesítési eljárások az Azure Identity Library for JavaScript használatával

Ez a cikk útmutatást nyújt a JavaScript- és TypeScript-alkalmazások teljesítményének és megbízhatóságának maximalizálásához az Azure-szolgáltatásokhoz való hitelesítés során. A JavaScripthez készült Azure Identity-kódtár kihasználása érdekében fontos megérteni a lehetséges problémákat és a megoldási technikákat.

Determinisztikus hitelesítő adatok használata éles környezetben

DefaultAzureCredential a legkönnyebb módja az Azure Identity könyvtár használatának megkezdésére, de ez a kényelem cserébe bizonyos áldozatokat követel. Előre nem lehet garantálni, hogy a láncban melyik hitelesítő adat lesz sikeres, és melyiket fogják használni a kérelem hitelesítéséhez. Gyártási környezetben ez a kiszámíthatatlanság jelentős és néha finom problémákat okozhat.

Vegyük például az események hipotetikus sorozatát:

  1. A szervezet biztonsági csapata arra kötelezi az összes alkalmazást, hogy felügyelt identitást használjon az Azure-erőforrások hitelesítéséhez.
  2. Egy Azure-beli virtuális gépen (VM-en) üzemeltetett JavaScript-alkalmazás hónapok óta sikeresen használja DefaultAzureCredential a felügyelt identitáson keresztüli hitelesítést.
  3. A támogatási csapat elmondása nélkül a fejlesztő telepíti az Azure CLI-t a virtuális gépre, és futtatja a az login parancsot az Azure-beli hitelesítéshez.
  4. Az Azure-környezetben az új külön konfigurációs változás miatt az eredeti felügyelt identitáson keresztüli hitelesítés váratlanul csendesen meghiúsul.
  5. DefaultAzureCredential kihagyja a sikertelen ManagedIdentityCredential, és megkeresi a következő elérhető hitelesítő adatot, amely AzureCliCredential.
  6. Az alkalmazás a felügyelt identitás helyett az Azure CLI hitelesítő adatait használja, ami sikertelen lehet, vagy a jogosultságok váratlan megemelését vagy csökkentését eredményezheti.

Az éles alkalmazásokban az ilyen típusú apró problémák vagy csendes hibák elkerülése érdekében helyettesítse DefaultAzureCredential egy konkrét TokenCredential implementációval, például ManagedIdentityCredential. Az elérhető hitelesítő adatokért tekintse meg az Azure Identity ügyfélkódtár dokumentációját .

Vegyük például az alábbi DefaultAzureCredential konfigurációt egy Express.js projektben:

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
);

Módosítsa az előző kódot úgy, hogy válasszon egy hitelesítő adatot azon környezet alapján, amelyben az alkalmazás fut:

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
);

Ebben a példában csak ManagedIdentityCredential termelésben használatos. A helyi fejlesztési környezet hitelesítési igényeit ezután a záradékban else meghatározott hitelesítő adatok sorozata kezeli.

Hitelesítési adat példányok újrafelhasználása

Ha lehetséges, használja újra a hitelesítő példányokat az alkalmazás rugalmasságának javítása és a Microsoft Entra ID-nak kibocsátott hozzáférési jogkivonat-kérelmek számának csökkentése érdekében. Amikor egy hitelesítő adatot újra felhasználnak, megkísérelnek lekérni egy jogkivonatot a mögöttes MSAL-függőség által felügyelt alkalmazás-jogkivonat-gyorsítótárból. További információért lásd: Token gyorsítótárazása az Azure Identity klienskönyvtárban.

A tokenek tárolási viselkedése különbözik a böngészők és a Node.js környezetek között. Node.js alkalmazásokban a jogkivonatok alapértelmezés szerint gyorsítótárazva vannak a memóriában, ami azt jelenti, hogy a gyorsítótár elveszik, amikor az alkalmazás újraindul. A böngészőalkalmazásokban a jogkivonatok a hitelesítési folyamattól és a konfigurációtól függően a böngésző tárterületén (localStorage vagy sessionStorage) tárolhatók. Ezeknek a különbségeknek a megértése fontos a különböző alkalmazástípusok hitelesítőadat-újrafelhasználási stratégiáinak megvalósításakor.

Fontos

Egy nagy forgalmú alkalmazás, amely nem használja fel újra a hitelesítő adatokat, HTTP 429-es korlátozásokkal szembesülhet a Microsoft Entra ID-től, ami alkalmazáskimaradásokhoz vezethet.

Az ajánlott hitelesítő adatok újrafelhasználási stratégiája alkalmazás-keretrendszerenként eltérő.

A hitelesítő adatok újbóli felhasználásának JavaScript-alkalmazásokban való implementálásához hozzon létre egyetlen hitelesítő példányt, és használja újra az összes ügyfélobjektumban:

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
);

Az Express.js alkalmazásokban tárolhatja a hitelesítő adatokat az alkalmazásbeállításokban, és elérheti azt az útvonalkezelőkben:

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'));

A token élettartamának és a gyorsítótárazási logikának a szükségességének megértése

Ha az Azure Identity Library hitelesítő adatait egy Azure SDK-ügyfélkódtár környezetén kívül használja, az Ön felelőssége lesz a jogkivonatok élettartamának és gyorsítótárazási viselkedésének kezelése az alkalmazásban.

Az refreshAfterTimestampAccessToken tulajdonságát, amely jelzi a felhasználóknak, hogy mikor lehet megkísérelni a jogkivonatok frissítését, az Azure SDK-ügyfélkódtárak automatikusan használják, amelyek az Azure Core-kódtártól függenek a jogkivonat frissítéséhez. A jogkivonatok gyorsítótárazását támogató Azure Identity-kódtár hitelesítő adatainak közvetlen használata esetén az alapjául szolgáló MSAL-gyorsítótár proaktívan, automatikusan frissül, amikor az refreshAfterTimestamp idő bekövetkezik. Ez a kialakítás lehetővé teszi, hogy az ügyfélkód meghívja a TokenCredential.getToken() parancsot minden alkalommal, amikor szükség van egy jogkivonatra, és delegálja a frissítést a kódtárba.

Ha csak szükség esetén szeretné hívni TokenCredential.getToken(), figyelje a refreshAfterTimestamp dátumot, és próbálja meg proaktívan frissíteni a tokent azután. Az adott megvalósítás az ügyfélen múlik.

A felügyelt identitás újrapróbálkozására vonatkozó stratégia ismertetése

A JavaScripthez készült Azure Identity-kódtár lehetővé teszi a felügyelt identitáson keresztüli hitelesítést.ManagedIdentityCredential A használat ManagedIdentityCredential módja hatással van az alkalmazott újrapróbálkozési stratégiára:

  • Ha ezt használja DefaultAzureCredential, a rendszer nem kísérel meg újrapróbálkozásokat végrehajtani, ha a kezdeti jogkivonat-beszerzési kísérlet meghiúsul, vagy rövid idő elteltével túllépi az időkorlátot. Ez a legkevésbé rugalmas megoldás, mert a hatékony fejlesztési belső ciklus érdekében "gyors kudarcra" van optimalizálva.
  • Bármilyen más megközelítés, mint például a ChainedTokenCredential vagy a közvetlen ManagedIdentityCredential:
    • Az újrapróbálkozások közötti időintervallum 0,8 másodperccel kezdődik, és alapértelmezés szerint legfeljebb öt újrapróbálkozási kísérlet történik. Ez a beállítás rugalmasságra van optimalizálva, de potenciálisan nemkívánatos késéseket okoz a fejlesztési belső ciklusban.
    • Az alapértelmezett újrapróbálkozási beállítások bármelyikének módosításához használja az Újrapróbálkozások tulajdonságot a beállításparaméteren. Például próbálkozzon újra legfeljebb háromszor, 0,5 másodperces kezdőintervallummal:
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)
    }
  }
);

A felügyelt identitás újrapróbálkozási szabályzatainak testreszabásával kapcsolatos további információkért tekintse meg a TokenCredentialOptionstól származó alábbi lehetőségek egyikét: