Delen via

JavaScript-apps verifiëren bij Azure-services met behulp van de Azure Identity-bibliotheek

Wanneer een toepassing toegang moet hebben tot een Azure-resource, zoals Storage, Key Vault of Cognitive Services, moet de toepassing worden geverifieerd bij Azure. Dit geldt voor alle toepassingen, ongeacht of deze zijn geïmplementeerd in Azure, on-premises zijn geïmplementeerd of in ontwikkeling zijn op een lokaal ontwikkelwerkstation. In dit artikel worden de aanbevolen methoden beschreven voor het verifiëren van een app bij Azure wanneer u de Azure SDK voor JavaScript gebruikt.

De aanbevolen methode is om ervoor te zorgen dat uw apps verificatie op basis van tokens gebruiken in plaats van verbindingsreeksen of sleutels bij het verifiëren bij Azure-resources. De Azure Identity-bibliotheek biedt verificatie op basis van tokens en stelt apps in staat om naadloos te verifiëren bij Azure-resources, ongeacht of de app zich in lokale ontwikkeling bevindt, in Azure is geïmplementeerd of op een on-premises server is geïmplementeerd.

Het specifieke type verificatie op basis van tokens dat een app moet gebruiken om te verifiëren bij Azure-resources, is afhankelijk van waar de app wordt uitgevoerd en wordt weergegeven in het volgende diagram.

Milieu Authenticatie
Lokaal Wanneer een ontwikkelaar een app uitvoert tijdens lokale ontwikkeling: de app kan worden geverifieerd bij Azure met behulp van een toepassingsservice-principal voor lokale ontwikkeling of met behulp van de Azure-referenties van de ontwikkelaar. Elk van deze opties wordt uitvoeriger besproken in de sectie verificatie bij lokale ontwikkeling.
Azure Wanneer een app wordt gehost in Azure: de app moet worden geverifieerd bij Azure-resources met behulp van een beheerde identiteit. Deze optie wordt hieronder uitgebreid besproken in de sectie authenticatie in serveromgevingen.
Ter plaatse Wanneer een app on-premises wordt gehost en geïmplementeerd: de app moet worden geverifieerd bij Azure-resources met behulp van een service-principal voor toepassingen. Deze optie wordt hieronder uitgebreid besproken in de sectie authenticatie in serveromgevingen.

een diagram met de aanbevolen verificatiestrategieën op basis van tokens voor een app, afhankelijk van waar deze wordt uitgevoerd.

Voordelen van verificatie op basis van tokens

Bij het bouwen van apps voor Azure raden we u ten zeerste aan om verificatie op basis van tokens te gebruiken in plaats van geheimen, zoals verbindingsreeksen of sleutels. DefaultAzureCredential biedt verificatie op basis van tokens.

Verificatie op basis van tokens Geheimen (verbindingsreeksen en sleutels)
Het principe van minimale bevoegdheden: stel de specifieke machtigingen in die nodig zijn voor de app in de Azure-resource. Een verbindingsreeks of sleutel verleent volledige rechten aan de Azure-resource.
Er is geen toepassingsgeheim om op te slaan. Geheimen moeten worden opgeslagen en geroteerd in de app-instellingen of als omgevingsvariabele.
De Azure Identity-bibliotheek beheert tokens voor u achter de schermen. Dit maakt het gebruik van verificatie op basis van tokens net zo eenvoudig als een verbindingsreeks. Geheimen worden niet beheerd.

Het gebruik van verbindingsreeksen moet worden beperkt tot het eerste bewijs van concept-apps of prototypen voor ontwikkeling die geen toegang hebben tot productie- of gevoelige gegevens. Anders moeten de verificatieklassen op basis van tokens die beschikbaar zijn in de Azure Identity-bibliotheek altijd de voorkeur krijgen bij het verifiëren bij Azure-resources.

Gebruik de volgende bibliotheek:

DefaultAzureCredential

Met de DefaultAzureCredential-klasse die wordt geleverd door de Azure Identity-bibliotheek, kunnen apps verschillende verificatiemethoden gebruiken, afhankelijk van de omgeving waarin ze worden uitgevoerd. Met dit gedrag kunnen apps zonder codewijzigingen worden gepromoveerd van lokale ontwikkeling naar testomgevingen en vervolgens naar productie. U configureert de juiste verificatiemethode voor elke omgeving en DefaultAzureCredential detecteert en gebruikt deze verificatiemethode automatisch. Het gebruik van DefaultAzureCredential moet de voorkeur hebben boven het handmatig coderen van voorwaardelijke logica of functievlagmen om verschillende verificatiemethoden in verschillende omgevingen te gebruiken.

Meer informatie over het gebruik van DefaultAzureCredential vindt u in Gebruik DefaultAzureCredential in een toepassing.

Verificatie in serveromgevingen

Bij het hosten in een serveromgeving moet aan elke toepassing een unieke toepassingsidentiteit per omgeving worden toegewezen. In Azure wordt een app-identiteit vertegenwoordigd door een service-principal, een speciaal type beveiligingsprincipaal dat is bedoeld om apps te identificeren en te verifiëren bij Azure. Het type service-principal dat voor uw app moet worden gebruikt, is afhankelijk van de locatie waarop uw app wordt uitgevoerd.

Verificatie tijdens lokale ontwikkeling

Wanneer een toepassing wordt uitgevoerd op het werkstation van een ontwikkelaar tijdens de lokale ontwikkeling, moet de lokale omgeving zich nog steeds verifiëren bij alle Azure-services die door de app worden gebruikt.

DefaultAzureCredential gebruiken in een toepassing

DefaultAzureCredential- is een bewust gekozen en geordende reeks van mechanismen voor authenticatie bij Microsoft Entra ID. Elk verificatiemechanisme is een klasse die is afgeleid van de TokenCredential-klasse en wordt een referentiegenoemd. Tijdens de uitvoertijd probeert DefaultAzureCredential te authenticeren met behulp van de eerste referentie. Als deze referentie geen toegangstoken kan verkrijgen, wordt de volgende referentie in de reeks geprobeerd, enzovoort, totdat een toegangstoken is verkregen. Op deze manier kan uw app verschillende referenties in verschillende omgevingen gebruiken zonder omgevingsspecifieke code te schrijven.

Als u DefaultAzureCredential wilt gebruiken, voegt u het @azure/identiteitspakket toe aan uw toepassing.

npm install @azure/identity

Vervolgens ziet u in het volgende codevoorbeeld hoe u een DefaultAzureCredential object instantieert en gebruikt met een Azure SDK-serviceclientklasse, in dit geval een BlobServiceClient gebruikt voor toegang tot Azure Blob Storage.

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 detecteert automatisch het verificatiemechanisme dat is geconfigureerd voor de app en haalt de benodigde tokens op om de app bij Azure te verifiëren. Als een toepassing gebruikmaakt van meer dan één SDK-client, kan hetzelfde referentieobject worden gebruikt voor elk SDK-clientobject.