JavaScript-apps verifiëren bij Azure-services met behulp van de Azure SDK voor JavaScript

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.

Aanbevolen methode voor app-verificatie

Het aanbevolen proces is om ervoor te zorgen dat uw apps verificatie op basis van tokens gebruiken in plaats van verbindingsreeks s of sleutels bij het verifiëren bij Azure-resources. De Azure SDK 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.

Omgeving	Verificatie
Lokale	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 sectieverificatie tijdens 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 sectieverificatie in serveromgevingen.
On-premises	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 sectieverificatie in serveromgevingen.

Voordelen van verificatie op basis van tokens

Bij het bouwen van apps voor Azure wordt verificatie op basis van tokens sterk aanbevolen voor geheimen (verbindingsreeks s of sleutels). Verificatie op basis van tokens wordt geleverd met DefaultAzureCredential.

Verificatie op basis van tokens	Geheimen (verbindingsreeks s 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 gedraaid in app-instelling of omgevingsvariabele.
De Azure Identity SDK 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 verbindingsreeks s 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 SDK altijd de voorkeur krijgen bij het verifiëren bij Azure-resources.

Gebruik de volgende SDK:

• @azure/identiteit

DefaultAzureCredential

Met de Azure SDK DefaultAzureCredential-methode kunnen apps verschillende verificatiemethoden gebruiken, afhankelijk van de omgeving waarin ze worden uitgevoerd. Hierdoor kunnen apps worden geïmplementeerd in lokale, test- en productieomgevingen zonder codewijzigingen. U configureert de juiste verificatiemethode voor elke omgeving en DefaultAzureCredential detecteert en gebruikt deze verificatiemethode automatisch. Het gebruik van is de voorkeur boven het handmatig coderen van DefaultAzureCredential voorwaardelijke logica of functievlagmen om verschillende verificatiemethoden in verschillende omgevingen te gebruiken.

Meer informatie over het gebruik van de klasse DefaultAzureCredential vindt u verderop in dit artikel in de sectie DefaultAzureCredential gebruiken 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

Als u DefaultAzureCredential wilt gebruiken in een JavaScript-app, 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-clientklasse, in dit geval een BlobServiceClient die wordt gebruikt voor toegang tot 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 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.

Volgorde van het selecteren van verificatiemethoden bij het gebruik van DefaultAzureCredential

DefaultAzureCredential Implementeert intern een keten van het selecteren van referentieproviders voor het verifiëren van toepassingen bij Azure-resources. Elke referentieprovider kan detecteren of referenties van dat type zijn geconfigureerd voor de app. DefaultAzureCredential Controleert elke provider op volgorde en gebruikt de referenties van de eerste provider waarvoor referenties zijn geconfigureerd.

Als u meer dan één referentie hebt geconfigureerd, is de volgorde van het vinden van de referentie via de keten belangrijk.

De volgorde waarin DefaultAzureCredential wordt gezocht naar referenties voor JavaScript, wordt weergegeven in het diagram en de onderstaande tabel.

Er zijn twee paden:

• Geïmplementeerde service (Azure of on-premises): de reeks begint met de omgevingsvariabelen, vervolgens de beheerde identiteit en vervolgens de rest van de locaties voor een referentie (Visual Studio Code, Azure CLI, Azure PowerShell).
• De lokale omgeving van de ontwikkelaar: de keten van het lokale ontwikkelaarswerkstation begint met de aangemelde Azure-gebruiker van Visual Studio Code, weergegeven in de onderste balk van de IDE, en gaat vervolgens verder naar de Azure CLI en vervolgens naar Azure PowerShell. Het is belangrijk om te begrijpen of u uw lokale omgevingsvariabelen hebt geconfigureerd, ofwel voor uw hele omgeving, of als de virtuele omgeving van een project (zoals met DOTENV), deze variabelen de Visual Studio Code -> Azure CLI -> PowerShell-keten overschrijven omdat ze de eerste referentie zijn die in de keten is gecontroleerd.

Referentietype	Beschrijving
Omgeving	DefaultAzureCredential leest een set omgevingsvariabelen om te bepalen of een toepassingsservice-principal (toepassingsgebruiker) is ingesteld voor de app. Als dat het zo is, DefaultAzureCredential gebruikt u 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.
Beheerde identiteit	Als de toepassing wordt geïmplementeerd op een Azure-host waarvoor Managed Identity is ingeschakeld, DefaultAzureCredential wordt de app geverifieerd bij Azure met behulp van die beheerde identiteit. Verificatie met behulp van een beheerde identiteit wordt besproken in de sectie Verificatie in serveromgevingen van dit document. Deze methode is alleen beschikbaar wanneer een toepassing wordt gehost in Azure met behulp van een service met beheerde identiteit.
Visual Studio Code	Als de ontwikkelaar is geverifieerd bij Azure met behulp van de invoegtoepassing Azure-account van Visual Studio Code, DefaultAzureCredential wordt de app geverifieerd bij Azure met hetzelfde account.
Azure-CLI	Als een ontwikkelaar is geverifieerd bij Azure met behulp van de az login opdracht in de Azure CLI, DefaultAzureCredential verifieert u de app bij Azure met hetzelfde account.
Azure PowerShell	Als een ontwikkelaar is geverifieerd bij Azure met behulp van de Connect-AzAccount cmdlet van Azure PowerShell, DefaultAzureCredential verifieert u de app bij Azure met hetzelfde account.
Interactief	Indien ingeschakeld, verifieert DefaultAzureCredential de ontwikkelaar interactief via de standaardbrowser van het huidige systeem. Deze optie is standaard uitgeschakeld.