Referentieketens in de Azure Identity-clientbibliotheek voor JavaScript

De Azure Identity-clientbibliotheek biedt referenties openbare klassen die de TokenCredential-interface van de Azure Core-bibliotheek implementeren. Een autorisatiegegeven vertegenwoordigt een afzonderlijke verificatiestroom voor het verkrijgen van een toegangstoken van Microsoft Entra ID. Deze referenties kunnen afzonderlijk worden geselecteerd of aan elkaar worden gekoppeld om een geordende reeks verificatiemechanismen te vormen die moeten worden geprobeerd.

• Afzonderlijke referenties bieden snelheid en zekerheid. Als ze mislukken, weet u dat de inloggegevens niet zijn geverifieerd.
• Chains bieden een terugvaloptie. Wanneer de referentie niet kan worden geverifieerd, wordt de volgende referentie in de keten geprobeerd.

Uw verificatiestromen ontwerpen

Wanneer u Azure SDK-clientbibliotheken gebruikt, is de eerste stap het verifiëren bij Azure. Er zijn veel opties voor verificatie om rekening mee te houden, zoals hulpprogramma's en IDE's die worden gebruikt in het ontwikkelteam, automatiseringswerkstromen zoals testen en CI/CD en hostingplatforms zoals Azure App Service.

Kies uit de volgende algemene voortgangen voor uw verificatiestroom:

• Gebruik de DefaultAzureCredential voor teams waarvan ontwikkelaars verschillende IDE's en CDI's gebruiken om te verifiëren bij Azure. Dit maakt de grootste flexibiliteit mogelijk. Deze flexibiliteit wordt geboden ten koste van de prestaties om de referenties in de keten te valideren totdat één slaagt.

  • De terugval van referentie naar referentie wordt namens u geselecteerd op basis van de gedetecteerde omgeving.
  • Als u wilt bepalen welke referentie is geselecteerd, schakelt u foutopsporingin.

• Gebruik de ChainedTokenCredential voor teams met een strikte en beperkte selectie van hulpprogramma's. Ze authenticeren allemaal en gebruiken dezelfde IDE of CLI. Hierdoor kan het team de exacte referenties en de volgorde selecteren die nog steeds flexibiliteit biedt, maar tegen lagere prestatiekosten.

  • U selecteert het terugvalpad van referentie naar referentie, ongeacht de omgeving waarin het wordt uitgevoerd.
  • Om te bepalen welke inloggegevens zijn geselecteerd, schakelt u foutopsporingin.

• Voor teams met zekerheid van referenties in alle omgevingen, kunt u met een controlestroominstructie, zoals if/else, weten welke referenties in elke omgeving zijn gekozen.

  • Er is geen terugval naar een ander referentietype.
  • U hoeft niet te debuggen om te bepalen welke inloggegevens zijn gekozen, omdat ze zijn gespecificeerd.

Hoe een gekoppelde referentie werkt

Tijdens runtime probeert een referentieketen te verifiëren met behulp van de eerste referentie van de reeks. Als deze referentie geen toegangstoken kan verkrijgen, wordt de volgende referentie in de reeks geprobeerd, enzovoort, totdat een toegangstoken is verkregen. In het volgende sequentiediagram ziet u dit gedrag:

DefaultAzureCredential gebruiken voor flexibiliteit

DefaultAzureCredential- is een specifiek, vooraf geconfigureerde keten van referenties. Het is ontworpen om veel omgevingen te ondersteunen, samen met de meest voorkomende verificatiestromen en ontwikkelhulpprogramma's. In grafische vorm ziet de onderliggende keten er als volgt uit:

De volgorde waarin DefaultAzureCredential referenties probeert.

Bevelen	Geloofsbrief	Beschrijving
1	Omgeving	Leest een verzameling omgevingsvariabelen om te bepalen of een toepassingsservice-principal (toepassingsgebruiker) is geconfigureerd voor de app. Zo ja, dan gebruikt DefaultAzureCredential deze waarden om de app te verifiëren bij Azure. Deze methode wordt meestal gebruikt in serveromgevingen, maar kan ook worden gebruikt bij het lokaal ontwikkelen.
2	Workload Identiteit	Als de app is geïmplementeerd op een Azure-host waarvoor workloadidentiteit is ingeschakeld, verifieert u dat account.
3	Beheerde Identiteit	Als de app is geïmplementeerd op een Azure-host waarvoor Managed Identity is ingeschakeld, verifieert u de app bij Azure met behulp van die beheerde identiteit.
4	Azure CLI	Als de ontwikkelaar is geverifieerd bij Azure met behulp van de opdracht az login van Azure CLI, moet u de app verifiëren bij Azure met hetzelfde account.
5	Azure PowerShell	Als de ontwikkelaar is geverifieerd bij Azure met behulp van de Connect-AzAccount-cmdlet van Azure PowerShell, moet u de app verifiëren bij Azure met hetzelfde account.
6	Azure Developer CLI	Als de ontwikkelaar zich heeft geauthenticeerd bij Azure met behulp van de azd auth login-opdracht van Azure Developer CLI, gebruik dan dat account om te verifiëren.

In de eenvoudigste vorm kunt u de parameterloze versie van DefaultAzureCredential als volgt gebruiken:

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

// Acquire a credential object
const credential = new DefaultAzureCredential();

const blobServiceClient = new BlobServiceClient(
    "https://<my_account_name>.blob.core.windows.net",
    credential
);

Referenties zijn globaal voor de omgeving

DefaultAzureCredential controleert op de aanwezigheid van bepaalde omgevingsvariabelen. Het is mogelijk dat iemand deze omgevingsvariabelen kan toevoegen of wijzigen op systeemniveau op de hostcomputer. Deze wijzigingen zijn globaal van toepassing en wijzigen daarom het gedrag van DefaultAzureCredential tijdens runtime in elke app die op die computer wordt uitgevoerd.

ChainedTokenCredential gebruiken voor granulariteit

ChainedTokenCredential is een lege keten waaraan u referentiële gegevens toevoegt die passen bij de behoeften van uw app. In het volgende voorbeeld wordt bijvoorbeeld een ManagedIdentityCredential exemplaar toegevoegd en vervolgens een AzureCliCredential exemplaar.

import { 
    ChainedTokenCredential, 
    ManagedIdentityCredential, 
    AzureCliCredential 
} from "@azure/identity";

const credential = ChainedTokenCredential(
    ManagedIdentityCredential({ clientId: "<YOUR_CLIENT_ID>" }),
    AzureCliCredential()
);

In het voorgaande codevoorbeeld wordt een aangepaste referentieketen gemaakt die bestaat uit twee referenties. De door de gebruiker toegewezen beheerde identiteitvariant van ManagedIdentityCredential wordt eerst geprobeerd, gevolgd door AzureCliCredential, indien nodig. In grafische vorm ziet de keten er als volgt uit:

Tip

Voor betere prestaties optimaliseert u de volgorde van referenties voor uw productieomgeving. Referenties die zijn bedoeld voor gebruik in de lokale ontwikkelomgeving, moeten als laatste worden toegevoegd.

Fouten opsporen in een gekoppelde referentie

Als u fouten in een referentieketen wilt opsporen, schakelt u Azure SDK-logboekregistratie in.

Meer middelen

• Azure CLI