Zelfstudie: Gebruikers eind-tot-eind verifiëren en autoriseren in Azure App Service

Azure App Service biedt een uiterst schaalbare webhostingservice met self-patchfunctie. App Service biedt ingebouwde ondersteuning voor gebruikersverificatie en autorisatie. In deze zelfstudie leest u hoe u apps kunt beveiligen met verificatie en autorisatie van App Service. Het maakt gebruik van een Express.js met weergave-front-end. App Service-verificatie en -autorisatie ondersteunen alle taalruntimes. U kunt leren hoe u deze toepast op uw voorkeurstaal door deze zelfstudie te volgen.

Azure App Service biedt een uiterst schaalbare webhostingservice met self-patchfunctie met behulp van het Linux-besturingssysteem. App Service biedt ingebouwde ondersteuning voor gebruikersverificatie en autorisatie. In deze zelfstudie leest u hoe u apps kunt beveiligen met verificatie en autorisatie van App Service. Het maakt gebruik van een Express.js met weergave-front-end. App Service-verificatie en -autorisatie ondersteunen alle taalruntimes. U kunt leren hoe u deze toepast op uw voorkeurstaal door deze zelfstudie te volgen.

De verificatie in deze procedure wordt geleverd op de hostingplatformlaag door Azure-app Service. U moet de front-end en back-end apps implementeren en authenticatie configureren, zodat deze web-app succesvol kan worden gebruikt.

Conceptueel diagram toont de verificatiestroom van de webgebruiker naar de front-end-app naar de back-end-app.

Nadat u dit scenario hebt voltooid, gaat u verder met de volgende zelfstudie om te leren hoe u verbinding maakt met Azure-services als geverifieerde gebruiker. Veelvoorkomende scenario's zijn het openen van Azure Storage of een database als de gebruiker met specifieke rechten of toegang tot bepaalde tabellen of bestanden.

In deze handleiding leert u:

Ingebouwde verificatie en autorisatie inschakelen
Apps beveiligen tegen niet-geverifieerde aanvragen
Microsoft Entra-id gebruiken als id-provider
Externe apps openen namens de aangemelde gebruiker
Aanroepen tussen services beveiligen met tokenverificatie
Toegangstokens gebruiken vanuit servercode

Vereisten

Als u geen Azure-account hebt, maak dan een gratis account aan voordat u begint.

Node.js (LTS)

Gebruik de Bash-omgeving in Azure Cloud Shell. Zie Aan de slag met Azure Cloud Shell voor meer informatie.
Installeer de Azure CLI, indien gewenst, om CLI-referentieopdrachten uit te voeren. Als u in Windows of macOS werkt, kunt u Azure CLI uitvoeren in een Docker-container. Zie De Azure CLI uitvoeren in een Docker-container voor meer informatie.
- Als u een lokale installatie gebruikt, meldt u zich aan bij Azure CLI met behulp van de opdracht az login. Volg de stappen die worden weergegeven in de terminal, om het verificatieproces te voltooien. Zie Verifiëren bij Azure met behulp van Azure CLI voor andere aanmeldingsopties.
- Installeer de Azure CLI-extensie bij het eerste gebruik, wanneer u hierom wordt gevraagd. Zie Extensies gebruiken en beheren met de Azure CLIvoor meer informatie over extensies.
- Voer az version uit om de geïnstalleerde versie en afhankelijke bibliotheken te vinden. Voer az upgrade uit om te upgraden naar de nieuwste versie.

Het gebruikersprofiel ophalen

De front-end-app is geconfigureerd om de back-end-API veilig te gebruiken. De front-endtoepassing biedt een Microsoft-aanmelding voor de gebruiker, waarna de gebruiker het nepprofiel van de back-end kan ophalen. In deze zelfstudie wordt een nepprofiel gebruikt om de stappen voor het voltooien van het scenario te vereenvoudigen.

Voordat uw broncode wordt uitgevoerd op de front-end, injecteert de App Service de geverifieerde accessToken code vanuit de App Service-header x-ms-token-aad-access-token . De front-endbroncode krijgt vervolgens toegang en verzendt de accessToken naar de back-endserver. De front-endserver verzendt het token als de bearerToken token om veilig toegang te krijgen tot de back-end-API. De back-endserver valideert de bearerToken voordat deze wordt doorgegeven aan uw back-endbroncode. Nadat de backend-broncode de bearerToken heeft ontvangen, kan deze worden gebruikt.

In de volgende zelfstudie in deze reeks wordt het bearerToken uitgewisseld voor een token met een bereik voor toegang tot de Microsoft Graph API. De Microsoft Graph API retourneert de profielgegevens van de gebruiker.

De voorbeeldtoepassing klonen

Voer in Azure Cloud Shell de volgende opdracht uit om de voorbeeldopslagplaats te klonen.

git clone https://github.com/Azure-Samples/js-e2e-web-app-easy-auth-app-to-app

Apps maken en implementeren

Maak de resourcegroep, het web-app-plan en de web-app en implementeer vervolgens in één stap.

Ga naar de map van de frontend web-app.

cd js-e2e-web-app-easy-auth-app-to-app/frontend

Maak en implementeer de front-end web-app met de opdracht az webapp up. De naam van de web-app moet wereldwijd uniek zijn. Vervang <front-end-app-name> door een unieke naam.

az webapp up --resource-group myAuthResourceGroup --name <front-end-app-name> --plan myPlan --sku FREE --os-type Windows --location "West Europe" --runtime "NODE:24LTS"

Ga naar de map van de backend web-app.
```
cd ../backend
```
Implementeer de back-endweb-app in dezelfde resourcegroep en hetzelfde app-plan. De naam van de web-app moet wereldwijd uniek zijn. Vervang door <back-end-app-name> een unieke tekenreeks met letters en cijfers.
```
az webapp up --resource-group myAuthResourceGroup --name <back-end-app-name> --plan myPlan --os-type Windows --location "West Europe" --runtime "NODE:24LTS"
```

Ga naar de map van de frontend web-app.
```
cd frontend
```
Maak en implementeer de front-end web-app met de opdracht az webapp up. De naam van de web-app moet wereldwijd uniek zijn. Vervang door <front-end-app-name> een unieke tekenreeks met letters en cijfers.
```
az webapp up --resource-group myAuthResourceGroup --name <front-end-app-name> --plan myPlan --sku FREE --location "West Europe" --os-type Linux --runtime "NODE:24-lts"
```
Ga naar de map van de backend web-app.
```
cd ../backend
```
Implementeer de back-endweb-app in dezelfde resourcegroep en hetzelfde app-plan. De naam van de web-app moet wereldwijd uniek zijn. Vervang door <back-end-app-name> een unieke tekenreeks met letters en cijfers.
```
az webapp up --resource-group myAuthResourceGroup --name <back-end-app-name> --plan myPlan --sku FREE --location "West Europe" --runtime "NODE:24-lts"
```

App-instelling configureren

De front-endtoepassing moet de URL van de back-endtoepassing voor API-aanvragen kennen. Gebruik de volgende Azure CLI-opdracht om de app-instelling te configureren. De URL moet zijn https://<back-end-app-name>.azurewebsites.net.

az webapp config appsettings set --resource-group myAuthResourceGroup --name <front-end-app-name> --settings BACKEND_URL="https://<back-end-app-name>.azurewebsites.net"

Front-end roept de back-end aan

Navigeer naar de front-end app en haal het nepprofiel op van de back-end. Met deze actie wordt gevalideerd of de front-end het profiel aanvraagt vanaf de back-end en dat de back-end het profiel retourneert.

Open de front-endweb-app in een browser: https://<front-end-app-name>.azurewebsites.net.
Selecteer de link Gebruikersprofiel ophalen.
Bekijk het valse profiel dat is geretourneerd vanuit de back-endweb-app.

De withAuthentication waarde onwaar geeft aan dat de verificatie nog niet is ingesteld.

Verificatie configureren

In deze sectie schakelt u verificatie en autorisatie in voor de twee web-apps. In deze handleiding wordt Microsoft Entra ID gebruikt als identiteitsprovider.

U configureert ook de front-end-app voor het volgende:

De front-end-app toegang verlenen tot de back-end-app
App Service configureren zodat een bruikbaar token wordt geretourneerd
Het token in uw code gebruiken

Zie Microsoft Entra-verificatie configureren voor uw App Services-toepassing voor meer informatie.

Verificatie en autorisatie inschakelen voor back-end-app

Zoek en selecteer Resourcegroepen in Azure Portal.
Zoek in Resourcegroepen uw resourcegroep en selecteer deze. Selecteer in Overzicht uw back-end-app.
Selecteer in het linkermenu van uw back-end-app instellingenverificatie> en selecteer vervolgens Id-provider toevoegen.
Selecteer Op de pagina Een id-provider toevoegen , voor id-provider, Microsoft om u aan te melden met behulp van Microsoft- en Microsoft Entra-identiteiten.
Selecteer een waarde voor het verlopen van het clientgeheim.
Accepteer voor de andere waarden de standaardinstellingen en selecteer Toevoegen.
De pagina Verificatie wordt geopend. Kopieer de client-ID van de Microsoft Entra-applicatie naar Kladblok. U hebt deze waarde later nog nodig.

Als u hier stopt, hebt u een zelfstandige app die de App Service-verificatie en -autorisatie veilig maakt. In de overige secties ziet u hoe u een oplossing voor meerdere apps kunt beveiligen door de geverifieerde gebruiker van de front-end naar de back-end te laten stromen .

Verificatie en autorisatie inschakelen voor front-end-app

Zoek en selecteer Resourcegroepen in Azure Portal.
Zoek in Resourcegroepen uw resourcegroep en selecteer deze. Selecteer in Overzicht uw front-end-app.
Selecteer in het linkermenu van uw front-end-app instellingenverificatie> en selecteer vervolgens Id-provider toevoegen.
Selecteer Op de pagina Een id-provider toevoegen , voor id-provider, Microsoft om u aan te melden met behulp van Microsoft- en Microsoft Entra-identiteiten.
Selecteer een waarde voor het verlopen van het clientgeheim. Accepteer voor de andere waarden de standaardinstellingen en selecteer Toevoegen.
De pagina Verificatie wordt geopend. Kopieer de client-ID van de Microsoft Entra-applicatie naar Kladblok. U hebt deze waarde later nog nodig.

Frontend app toegang verlenen tot de backend app

U hebt verificatie en autorisatie ingeschakeld voor beide apps. Als u de verificatie wilt voltooien, moet u drie dingen doen:

De back-end-app beschikbaar maken als API door een bereik te definiëren
De front-end-app toegang verlenen tot de back-end-app
App Service configureren zodat een bruikbaar token wordt geretourneerd
Het token in uw code gebruiken

Opmerking

Voordat u de front-end-app toegang tot de back-end kunt verlenen, moet u de back-end-API beschikbaar maken door een URI voor de toepassings-id in te stellen en ten minste één bereik te definiëren. Hierdoor kan de back-end worden geselecteerd onder 'Mijn API's' bij het toewijzen van API-machtigingen.

Aanbeveling

Als u fouten ondervindt en de verificatie-/autorisatie-instellingen van uw app opnieuw configureert, worden de tokens in het tokenarchief mogelijk niet opnieuw gegenereerd vanuit de nieuwe instellingen. Als u ervoor wilt zorgen dat uw tokens opnieuw worden gegenereerd, moet u zich afmelden en weer aanmelden bij uw app. Een benadering is het gebruik van uw browser in de privémodus. Sluit de browser en open deze opnieuw in de privémodus nadat u de instellingen in uw apps hebt gewijzigd.

In deze sectie verleent u de front-end-app toegang tot de back-end-app namens de gebruiker. Technisch gezien geeft u de AD-toepassing van de front-end de machtigingen voor toegang tot de AD-toepassing van de back-end namens de gebruiker.

Selecteer op de pagina Verificatie voor de front-end-app onder Id-provider de naam van uw front-end-app. Deze app-registratie is automatisch voor u gegenereerd.
Selecteer API-machtigingen beheren> in het linkermenu.
Selecteer Een machtiging toevoegen en selecteer
Selecteer op de pagina Api-machtigingen aanvragen voor de back-end-app gedelegeerde machtigingen en user_impersonation en selecteer vervolgens Machtigingen toevoegen.

App Service configureren zodat een bruikbaar toegangstoken wordt geretourneerd

De front-end-app heeft nu de vereiste machtigingen voor toegang tot de back-end-app als de aangemelde gebruiker. In deze sectie configureert u App Service-verificatie en -autorisatie om u een bruikbaar toegangstoken te bieden voor toegang tot de back-end. Voor deze stap hebt u de client-id van de back-end nodig die u hebt gekopieerd uit Verificatie en autorisatie inschakelen voor de back-end-app.

Voer in Cloud Shell de volgende opdrachten uit in de front-end-app om de parameter toe te voegen aan de scope verificatie-instelling identityProviders.azureActiveDirectory.login.loginParameters. Vervang < en >.

az extension add --name authV2
authSettings=$(az webapp auth show -g myAuthResourceGroup -n <front-end-app-name>)
authSettings=$(echo "$authSettings" | jq '.properties' | jq '.identityProviders.azureActiveDirectory.login += {"loginParameters":["scope=openid offline_access api://<back-end-client-id>/user_impersonation"]}')
az webapp auth set --resource-group myAuthResourceGroup --name <front-end-app-name> --body "$authSettings"

De opdrachten voegen een loginParameters eigenschap toe met andere aangepaste scopes. Hier volgt een uitleg van de aangevraagde bereiken:

openid wordt standaard al aangevraagd door App Service. Zie OpenID Connect-bereiken voor meer informatie.
offline_access is hier voor het gemak opgenomen, voor het geval u tokens wilt vernieuwen.
api://<back-end-client-id>/user_impersonation is een openbare API in de registratie van uw back-end-app. Dit is de reikwijdte waarmee u een JWT krijgt die de back-end-app als token publiek omvat.

Aanbeveling

Als u het api://<back-end-client-id>/user_impersonation bereik in Azure Portal wilt weergeven, gaat u naar de pagina Verificatie voor de back-end-app, selecteert u de koppeling onder Id-provider en selecteert u Vervolgens Een API beschikbaar maken in het linkermenu.
Als u in plaats daarvan de vereiste scopes wilt configureren met behulp van een webinterface, raadpleegt u Verificatietokens vernieuwen.
Voor sommige bereiken is beheerders- of gebruikerstoestemming vereist. Deze vereiste zorgt ervoor dat de pagina voor toestemmingsaanvragen wordt weergegeven wanneer een gebruiker zich aanmeldt bij de front-end-app in de browser. Als u deze toestemmingspagina wilt voorkomen, voegt u de app-registratie van de front-end toe als een geautoriseerde clienttoepassing op de pagina Een API beschikbaar maken. Selecteer Een clienttoepassing toevoegen en geef de client-id van de app-registratie van de front-end op.

Uw apps zijn nu geconfigureerd. De front-end is nu gereed om met een juiste toegangstoken toegang te krijgen tot de back-end.

Zie Toegangstokens van id-providers vernieuwen voor informatie over het configureren van het toegangstoken voor andere providers.

Back-end-App Service configureren om alleen een token van de front-end-App Service te accepteren

U moet ook de back-end-App Service zo configureren dat alleen een token van de front-end-App Service wordt geaccepteerd. Als u deze configuratie niet uitvoert, resulteert dit in een fout 403: Verboden wanneer u het token van de front-end doorgeeft aan de back-end.

U kunt deze benadering implementeren met behulp van hetzelfde Azure CLI-proces dat u in de vorige stap hebt gebruikt.

Haal de appId front-end App Service op. U kunt deze waarde ophalen op de pagina Verificatie van de front-end App Service.
Voer de volgende Azure CLI uit, zorg ervoor dat u <back-end-app-name> en <front-end-app-id> vervangt.

authSettings=$(az webapp auth show -g myAuthResourceGroup -n <back-end-app-name>)
authSettings=$(echo "$authSettings" | jq '.properties' | jq '.identityProviders.azureActiveDirectory.validation.defaultAuthorizationPolicy.allowedApplications += ["<front-end-app-id>"]')
az webapp auth set --resource-group myAuthResourceGroup --name <back-end-app-name> --body "$authSettings"

Front-end roept de geverifieerde back-end aan

De front-end-app moet de authenticatie van de gebruiker verzenden met de juiste user_impersonation scope naar de back-end. In de volgende stappen wordt de code in het voorbeeld voor deze functionaliteit gecontroleerd.

Bekijk de broncode van de front-end-app:

Gebruik de front-end-header van App Service x-ms-token-aad-access-token om programmatisch het accessToken van de gebruiker op te halen.
```
// ./src/server.js
const accessToken = req.headers['x-ms-token-aad-access-token'];
```

Gebruik het accessToken in de Authentication header als de bearerToken waarde.

// ./src/remoteProfile.js
// Get profile from backend
const response = await fetch(remoteUrl, {
    cache: "no-store", // no caching -- for demo purposes only
    method: 'GET',
    headers: {
        'Authorization': `Bearer ${accessToken}`
    }
});
if (response.ok) {
    const { profile } = await response.json();
    console.log(`profile: ${profile}`);
} else {
    // error handling
}

Deze zelfstudie retourneert een nepprofiel om het scenario te vereenvoudigen. De volgende zelfstudie in deze reeks laat zien hoe u de back-end kunt omruilen voor een nieuw token binnen de context van een downstream Azure-service, zoals Microsoft Graph.

Back-end stuurt profiel naar front-end

Als de aanvraag van de front-end niet is geautoriseerd, weigert de back-end-App Service de aanvraag met een HTTP-foutcode van 401 voordat de aanvraag de toepassingscode bereikt. Wanneer de back-endcode is bereikt, omdat deze een geautoriseerd token bevat, extraheert u de bearerToken om de accessToken te verkrijgen.

Bekijk de broncode van de back-end-app:

// ./src/server.js
const bearerToken = req.headers['Authorization'] || req.headers['authorization'];

if (bearerToken) {
    const accessToken = bearerToken.split(' ')[1];
    console.log(`backend server.js accessToken: ${!!accessToken ? 'found' : 'not found'}`);

    // TODO: get profile from Graph API
    // provided in next article in this series
    // return await getProfileFromMicrosoftGraph(accessToken)

    // return fake profile for this tutorial
    return {
        "displayName": "John Doe",
        "withAuthentication": !!accessToken ? true : false
    }
}

Naar de apps bladeren

Gebruik de front-endwebsite in een browser. De URL is https://<front-end-app-name>.azurewebsites.net/.
De browser vraagt uw verificatie aan de web-app aan. Voltooi de verificatie.
Nadat de verificatie is voltooid, retourneert de front-endtoepassing de startpagina van de app.
Selecteer Het profiel van de gebruiker ophalen. Met deze actie wordt uw verificatie in het Bearer-token doorgegeven aan de back-end.
De back-end reageert met de valse , in code vastgelegde profielnaam: John Doe.

De withAuthentication waarde waar geeft aan dat de verificatie nu is ingesteld.

De hulpbronnen opschonen

In de voorgaande stappen hebt u Azure-resources in een resourcegroep gemaakt.

Verwijder de resourcegroep door de volgende opdracht uit te voeren in Cloud Shell. Het kan een minuut duren voordat deze opdracht is uitgevoerd.
```
az group delete --name myAuthResourceGroup
```
Gebruik de client-id van de verificatie-apps, die u eerder hebt gevonden en genoteerd in de Enable authentication and authorization secties voor de back-end- en front-end-apps.

Verwijder app-registraties voor zowel front-end- als back-end-apps.

# delete app - do this for both frontend and backend client ids
az ad app delete --id <client-id>

Veelgestelde vragen

Hoe kan ik deze verificatie testen op mijn lokale ontwikkelcomputer?

De verificatie in deze procedure wordt geleverd op de hostingplatformlaag door Azure-app Service. Er is geen equivalente emulator. U moet de front-end- en back-end-app implementeren en verificatie configureren voor elk zodat het gebruik kan maken van verificatie.

De app geeft geen nepprofiel weer, hoe kan ik fouten opsporen?

De front- en back-end-apps hebben /debug routes om het debuggen van de authenticatie te helpen wanneer deze toepassing het nepprofiel niet retourneert. De front-end-foutopsporingsroute biedt de kritieke onderdelen om te valideren:

Omgevingsvariabelen:
- De BACKEND_URL is correct geconfigureerd als https://<back-end-app-name>.azurewebsites.net. Neem die afsluitende schuine streep of de route niet op.
HTTP-headers:
- De x-ms-token-* headers worden geïnjecteerd.
Microsoft Graph-profielnaam voor aangemelde gebruiker wordt weergegeven.
Het bereik van de front-end-app voor het token heeft user_impersonation. Als uw bereik deze waarde niet bevat, kan het een probleem met timing zijn. Controleer de parameters van login uw front-end-app in Azure-resources. Wacht enkele minuten tot de replicatie van de verificatie is uitgevoerd.

Is de broncode van de toepassing correct geïmplementeerd voor elke web-app?

In de Azure Portal voor de web-app, selecteer Ontwikkelhulpprogramma's>Geavanceerde Hulpmiddelen, en selecteer vervolgens Ga. Met deze actie wordt een nieuw browsertabblad of -venster geopend.
Selecteer in het nieuwe browsertabblad Bladeren door directory>Site wwwroot.
Controleer of het volgende zich in de map bevindt:
- package.json
- node_modules.tar.gz
- /src/index.js
Controleer of de eigenschappackage.jsonname hetzelfde is als de webnaam of frontendbackend.
Als u de broncode hebt gewijzigd en opnieuw moet implementeren, gebruikt u de opdracht az webapp up in de map met het package.json-bestand voor die app.

Is de toepassing correct gestart?

Beide web-apps moeten iets retourneren wanneer de startpagina wordt aangevraagd. Als u geen toegang /debug hebt tot een web-app, is de app niet correct gestart. Bekijk de foutenlogboeken voor die web-app.

In de Azure Portal voor de web-app, selecteer Ontwikkelhulpprogramma's>Geavanceerde Hulpmiddelen, en selecteer vervolgens Ga. Met deze actie wordt een nieuw browsertabblad of -venster geopend.
Selecteer in het nieuwe browsertabblad Bladeren door de directory>Implementatielogboeken.
Bekijk elk logboek om gerapporteerde problemen te vinden.

Kan de front-end-app communiceren met de back-end-app?

Omdat de front-end-app de back-end-app aanroept vanuit de broncode van de server, is dit gedrag niet te zien in het netwerkverkeer van de browser. Gebruik de volgende lijst om te bepalen of de back-endprofielaanvraag is geslaagd:

De back-endweb-app retourneert eventuele fouten naar de front-end-app als deze is benaderd. Als dit niet is bereikt, rapporteert de front-end-app de statuscode en het bericht.
- 401: De gebruiker heeft verificatie niet correct doorgegeven. Dit bericht kan aangeven dat het bereik niet juist is ingesteld.
- 404: De URL naar de server komt niet overeen met een route die de server heeft
Gebruik de streaminglogboeken van de back-end-app om te kijken wanneer u de front-endaanvraag voor het profiel van de gebruiker doet. Er is foutopsporingsinformatie in de broncode waarmee u kunt bepalen waar de storing is opgetreden console.log.

Wat gebeurt er wanneer het front-end token verloopt?

Uw toegangstoken verloopt na bepaalde tijd. Voor meer informatie over het vernieuwen van uw toegangstokens zonder dat gebruikers zich opnieuw moeten verifiëren bij uw app raadpleegt u Toegangstokens van id-providers vernieuwen.

Als ik een browser-app op de front-end-app heb, kan deze rechtstreeks met de back-end communiceren?

Voor deze aanpak moet de servercode het toegangstoken doorgeven aan de JavaScript-code die wordt uitgevoerd in de clientbrowser. Omdat er geen manier is om het toegangstoken in de browser te beveiligen, raden we deze methode niet aan. Momenteel raden we het patroon Backend-for-Frontend aan.

Als deze toepassing wordt toegepast op het voorbeeld in deze zelfstudie, maakt de browsercode in de front-end-app API-aanroepen in een geverifieerde sessie met de servercode als intermediair. De servercode in de front-end-app maakt vervolgens de API-aanroepen naar de back-end-app met behulp van de x-ms-token-aad-access-token headerwaarde als bearer-token. Alle aanroepen van uw browsercode naar de servercode worden beveiligd door de geverifieerde sessie.

Volgende stap

Ga naar de volgende zelfstudie voor meer informatie over het gebruik van de identiteit van deze gebruiker voor toegang tot een Azure-service.

Een beveiligde n-tier-app maken in Azure-app Service

Feedback

Is deze pagina nuttig?

Last updated on 2025-07-08