Uw App Service- of Azure Functions-app configureren voor het gebruik van Microsoft Entra-aanmelding

Selecteer een andere verificatieprovider om naar deze provider te gaan.

In dit artikel leest u hoe u verificatie configureert voor Azure-app Service of Azure Functions, zodat uw app gebruikers aanmeldt met het Microsoft Identity Platform (Microsoft Entra ID) als verificatieprovider.

De functie App Service-verificatie kan automatisch een app-registratie maken met het Microsoft Identity Platform. U kunt ook een registratie gebruiken die u of een adreslijstbeheerder afzonderlijk maakt.

• Automatisch een nieuwe app-registratie maken
• Een bestaande registratie afzonderlijk gebruiken

Optie 1: Automatisch een nieuwe app-registratie maken

Gebruik deze optie, tenzij u een app-registratie afzonderlijk moet maken. U kunt de app-registratie in Microsoft Entra ID aanpassen zodra deze is gemaakt.

1. Meld u aan bij Azure Portal en navigeer naar uw app.

2. Selecteer Verificatie in het menu links. Selecteer Id-provider toevoegen.

3. Selecteer Microsoft in de vervolgkeuzelijst id-provider. De optie voor het maken van een nieuwe registratie is standaard geselecteerd. U kunt de naam van de registratie of de ondersteunde accounttypen wijzigen.

   Er wordt een clientgeheim gemaakt en opgeslagen als een site-sticky toepassingsinstelling met de naam MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. U kunt deze instelling later bijwerken om Key Vault-verwijzingen te gebruiken als u het geheim wilt beheren in Azure Key Vault.

4. Als dit de eerste id-provider is die is geconfigureerd voor de toepassing, wordt u ook gevraagd om een sectie met app Service-verificatie-instellingen . Anders kunt u verdergaan met de volgende stap.

   Deze opties bepalen hoe uw toepassing reageert op niet-geverifieerde aanvragen en de standaardselecties leiden alle aanvragen om zich aan te melden met deze nieuwe provider. U kunt dit gedrag nu aanpassen of deze instellingen later aanpassen vanuit het hoofdscherm voor verificatie door Bewerken naast verificatie-instellingen te kiezen. Zie de verificatiestroom voor meer informatie over deze opties.

5. (Optioneel) Selecteer Volgende: Machtigingen en voeg eventuele Microsoft Graph-machtigingen toe die nodig zijn voor de toepassing. Deze worden toegevoegd aan de app-registratie, maar u kunt ze later ook wijzigen.

6. Selecteer Toevoegen.

U bent nu klaar om het Microsoft Identity Platform te gebruiken voor verificatie in uw app. De provider wordt weergegeven op het verificatiescherm . Van daaruit kunt u deze providerconfiguratie bewerken of verwijderen.

Zie deze zelfstudie voor een voorbeeld van het configureren van Microsoft Entra-aanmelding voor een web-app die toegang heeft tot Azure Storage en Microsoft Graph.

Optie 2: Gebruik een bestaande registratie die afzonderlijk is gemaakt

U kunt App Service-verificatie configureren voor het gebruik van een bestaande app-registratie. De volgende situaties zijn de meest voorkomende gevallen voor het gebruik van een bestaande app-registratie:

• Uw account heeft geen machtigingen voor het maken van app-registraties in uw Microsoft Entra-tenant.
• U wilt een app-registratie van een andere Microsoft Entra-tenant gebruiken dan waarin uw app zich bevindt.
• De optie voor het maken van een nieuwe registratie is niet beschikbaar voor overheidsclouds.

Stap 1: Een app-registratie maken in Microsoft Entra ID voor uw App Service-app

Verzamel tijdens het maken van de app-registratie de volgende informatie die u later nodig hebt wanneer u de verificatie in de App Service-app configureert:

• Client ID
• Tenant-id
• Clientgeheim (optioneel, maar aanbevolen)
• Sollicitatie-ID URI

De instructies voor het maken van een app-registratie zijn afhankelijk van of u een personeelstenant of een klanttenant gebruikt. Gebruik de onderstaande tabbladen om de juiste set instructies voor uw scenario te selecteren.

Voer de volgende stappen uit om de app te registreren:

1. Meld u aan bij Azure Portal, zoek en selecteer App Services en selecteer vervolgens uw app. Noteer de URL van uw app. U gebruikt deze om uw Microsoft Entra-app-registratie te configureren.

2. Navigeer naar uw tenant in de portal:

   • Personeelstenant
   • Tenant van klant

   Selecteer Microsoft Entra ID in het portalmenu. Als de tenant die u gebruikt verschilt van de tenant die u gebruikt om de App Service-toepassing te configureren, moet u eerst mappen wijzigen.

3. Noteer in het scherm Overzicht de tenant-id en het primaire domein.

4. Selecteer in het linkernavigatievenster App-registraties> Nieuwe registratie.

5. Voer op de pagina Een toepassing registreren een naam in voor uw app-registratie.

6. Selecteer in Ondersteunde accounttypen het accounttype dat toegang heeft tot deze toepassing.

7. Selecteer In de sectie Omleidings-URI's web voor platform en typt <app-url>/.auth/login/aad/callbacku . Bijvoorbeeld: https://contoso.azurewebsites.net/.auth/login/aad/callback.

8. Selecteer Registreren.

9. Nadat de app-registratie is gemaakt, kopieert u de toepassings-id (client) en de map-id (tenant) voor later gebruik.

10. Selecteer Verificatie in het linkernavigatievenster. Schakel onder Impliciete toekenning en hybride stromen id-tokens in om OpenID-Verbinding maken gebruikersaanmelding vanuit App Service toe te staan. Selecteer Opslaan.

11. (Optioneel) Selecteer in het linkernavigatievenster de optie Huisstijl en eigenschappen. Voer in de URL van de startpagina de URL van uw App Service-app in en selecteer Opslaan.

12. Selecteer in het linkernavigatievenster een API>Toevoegen opslaan beschikbaar maken.> Deze waarde identificeert de toepassing uniek wanneer deze wordt gebruikt als resource, zodat tokens kunnen worden aangevraagd die toegang verlenen. Het wordt gebruikt als voorvoegsel voor bereiken die u maakt.

    Voor een app met één tenant kunt u de standaardwaarde gebruiken, die zich in het formulier bevindt api://<application-client-id>. U kunt ook een beter leesbare URI opgeven, zoals https://contoso.com/api op basis van een van de geverifieerde domeinen voor uw tenant. Voor een app met meerdere tenants moet u een aangepaste URI opgeven. Zie de naslaginformatie over aanbevolen procedures voor app-registraties voor meer informatie over geaccepteerde indelingen voor app-id-URI's.

13. Selecteer Een bereik toevoegen.

    1. Voer in bereiknaam user_impersonation in.
    2. Selecteer in Wie toestemming Beheer s en gebruikers als u wilt toestaan dat gebruikers toestemming geven voor dit bereik.
    3. Voer in de tekstvakken de naam en beschrijving van het toestemmingsbereik in die gebruikers moeten zien op de toestemmingspagina. Voer bijvoorbeeld de naam> van de Access-toepassing <in.
    4. Selecteer Bereik toevoegen.

14. (Optioneel) Een clientgeheim maken:

    1. Selecteer in het linkernavigatievenster Certificaten en geheimen Clientgeheimen>>Nieuw clientgeheim.
    2. Voer een beschrijving en vervaldatum in en selecteer Toevoegen.
    3. Kopieer in het veld Waarde de waarde van het clientgeheim. Deze wordt niet meer weergegeven wanneer u van deze pagina weg navigeert.

15. (Optioneel) Als u meerdere antwoord-URL's wilt toevoegen, selecteert u Verificatie.

16. Voltooi het instellen van uw app-registratie:

    • Personeelstenant
    • Tenant van klant

    Er zijn geen andere stappen vereist voor een personeelstenant.

Stap 2: Microsoft Entra-id inschakelen in uw App Service-app

1. Meld u aan bij Azure Portal en navigeer naar uw app.

2. Selecteer in het linkernavigatievenster verificatie-provider>>toevoegen Microsoft.

3. Selecteer het tenanttype van de app-registratie die u hebt gemaakt.

4. Configureer de app voor het gebruik van de registratie die u hebt gemaakt, met behulp van de instructies voor het juiste tenanttype:

   • Personeelstenant
   • Tenant van klant

   Kies een van de volgende opties voor app-registratietype:

   • Kies een bestaande app-registratie in deze map: kies een app-registratie uit de huidige tenant en verzamel automatisch de benodigde app-gegevens. Het systeem probeert een nieuw clientgeheim te maken voor de app-registratie en configureert automatisch uw app om deze te gebruiken. Er wordt een standaard-URL voor verleners ingesteld op basis van de ondersteunde accounttypen die zijn geconfigureerd in de app-registratie. Als u deze standaardinstelling wilt wijzigen, raadpleegt u de volgende tabel.
   • Geef de details op van een bestaande app-registratie: geef details op voor een app-registratie van een andere tenant of als uw account niet gemachtigd is in de huidige tenant om een query uit te voeren op de registraties. Voor deze optie moet u de configuratiewaarden handmatig invullen volgens de volgende tabel.

   Het verificatie-eindpunt voor een personeelstenant moet een waarde zijn die specifiek is voor de cloudomgeving. Een personeelstenant in globale Azure gebruikt bijvoorbeeld 'https://login.microsoftonline.com" als verificatie-eindpunt. Noteer de waarde van het verificatie-eindpunt, omdat deze nodig is om de juiste URL voor verleners samen te stellen.

   Wanneer u de configuratiegegevens rechtstreeks invult, gebruikt u de waarden die u hebt verzameld tijdens het maken van de app-registratie:

   Veld	Beschrijving
   Client-id van toepassing	Gebruik de toepassings-id (client) van de app-registratie.
   Clientgeheim	Gebruik het clientgeheim dat u hebt gegenereerd in de app-registratie. Met een clientgeheim wordt hybride stroom gebruikt en retourneert App Service toegangs- en vernieuwingstokens. Wanneer het clientgeheim niet is ingesteld, wordt impliciete stroom gebruikt en wordt alleen een id-token geretourneerd. Deze tokens worden verzonden door de provider en opgeslagen in het App Service-verificatietokenarchief.
   URL van verlener	Gebruik <authentication-endpoint>/<tenant-id>/v2.0en vervang <het verificatie-eindpunt door het verificatie-eindpunt> dat u in de vorige stap hebt bepaald voor uw tenanttype en cloudomgeving, waarbij ook tenant-id wordt vervangen door< de directory-id> (tenant) waarin de app-registratie is gemaakt. Laat de URL weg /v2.0 voor toepassingen die gebruikmaken van Azure AD v1. Deze waarde wordt gebruikt om gebruikers om te leiden naar de juiste Microsoft Entra-tenant, en om de juiste metagegevens te downloaden om bijvoorbeeld de juiste tokenondertekeningssleutels en claimwaarde voor tokenverleners te bepalen. Elke andere configuratie dan een tenantspecifiek eindpunt wordt behandeld als meerdere tenants. In configuraties met meerdere tenants wordt er geen validatie van de verlener of tenant-id uitgevoerd door het systeem. Deze controles moeten volledig worden verwerkt in de autorisatielogica van uw app.
   Toegestane tokendoelpunten	Dit veld is optioneel. De geconfigureerde toepassings-id (client) wordt altijd impliciet beschouwd als een toegestane doelgroep. Als uw toepassing een API vertegenwoordigt die door andere clients wordt aangeroepen, moet u ook de URI voor de toepassings-id toevoegen die u hebt geconfigureerd voor de app-registratie. Er geldt een limiet van 500 tekens in de lijst met toegestane doelgroepen.

   Het clientgeheim wordt opgeslagen als een site-sticky toepassingsinstelling met de naam MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. U kunt deze instelling later bijwerken om Key Vault-verwijzingen te gebruiken als u het geheim wilt beheren in Azure Key Vault.

5. Als dit de eerste id-provider is die is geconfigureerd voor de toepassing, wordt u ook gevraagd om een sectie met app Service-verificatie-instellingen . Anders kunt u verdergaan met de volgende stap.

   Deze opties bepalen hoe uw toepassing reageert op niet-geverifieerde aanvragen en de standaardselecties leiden alle aanvragen om zich aan te melden met deze nieuwe provider. U kunt dit gedrag nu aanpassen of deze instellingen later aanpassen vanuit het hoofdscherm voor verificatie door Bewerken naast verificatie-instellingen te kiezen. Zie de verificatiestroom voor meer informatie over deze opties.

6. Selecteer Toevoegen.

U bent nu klaar om het Microsoft Identity Platform te gebruiken voor verificatie in uw app. De provider wordt weergegeven op het verificatiescherm . Van daaruit kunt u deze providerconfiguratie bewerken of verwijderen.

Aanvragen autoriseren

App Service-verificatie verwerkt standaard alleen verificatie en bepaalt of de beller is wie ze zeggen dat ze zijn. Autorisatie, waarbij wordt bepaald of die beller toegang moet hebben tot een bepaalde resource, is een extra stap verder dan verificatie. Meer informatie over deze concepten vindt u in de basisprincipes van autorisatie van Microsoft Identity Platform.

Uw app kan autorisatiebeslissingen nemen in code. App Service-verificatie biedt wel een aantal ingebouwde controles, wat kan helpen, maar ze zijn mogelijk niet alleen voldoende om de autorisatiebehoeften van uw app te dekken.

Validaties uitvoeren vanuit toepassingscode

Wanneer u autorisatiecontroles uitvoert in uw app-code, kunt u gebruikmaken van de claimgegevens die App Service-verificatie beschikbaar maakt. De geïnjecteerde x-ms-client-principal header bevat een Met Base64 gecodeerd JSON-object met de claims die over de aanroeper zijn assertie. Deze claims doorlopen standaard een claimtoewijzing, zodat de claimnamen mogelijk niet altijd overeenkomen met wat u in het token zou zien. De claim wordt bijvoorbeeld tid toegewezen aan http://schemas.microsoft.com/identity/claims/tenantid .

U kunt ook rechtstreeks met het onderliggende toegangstoken werken vanuit de geïnjecteerde x-ms-token-aad-access-token header.

Een ingebouwd autorisatiebeleid gebruiken

De gemaakte app-registratie verifieert binnenkomende aanvragen voor uw Microsoft Entra-tenant. Standaard kan iedereen binnen de tenant toegang krijgen tot de toepassing. Dit is prima voor veel toepassingen. Sommige toepassingen moeten de toegang echter verder beperken door autorisatiebeslissingen te nemen. Uw toepassingscode is vaak de beste plaats om aangepaste autorisatielogica te verwerken. Voor veelvoorkomende scenario's biedt het Microsoft Identity Platform echter ingebouwde controles die u kunt gebruiken om de toegang te beperken.

In deze sectie wordt beschreven hoe u ingebouwde controles inschakelt met behulp van de App Service-verificatie-V2-API. Momenteel is de enige manier om deze ingebouwde controles te configureren via Azure Resource Manager-sjablonen of de REST API.

Binnen het API-object heeft de configuratie van de Microsoft Entra-id-provider een validation sectie die een defaultAuthorizationPolicy object kan bevatten zoals in de volgende structuur:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}

Daarnaast kunnen sommige controles worden geconfigureerd via een toepassingsinstelling, ongeacht de API-versie die wordt gebruikt. De WEBSITE_AUTH_AAD_ALLOWED_TENANTS toepassingsinstelling kan worden geconfigureerd met een door komma's gescheiden lijst met maximaal 10 tenant-id's (bijvoorbeeld "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc") om te vereisen dat het binnenkomende token afkomstig is van een van de opgegeven tenants, zoals opgegeven door de tid claim. De WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL toepassingsinstelling kan worden geconfigureerd op 'true' of '1' om te vereisen dat het binnenkomende token een oid claim bevat. Deze instelling wordt genegeerd en behandeld als waar als allowedPrincipals.identities deze is geconfigureerd (omdat de oid claim is gecontroleerd op basis van deze opgegeven lijst met identiteiten).

Aanvragen waarvoor deze ingebouwde controles mislukken, krijgen een HTTP-antwoord 403 Forbidden .

Client-apps configureren voor toegang tot uw App Service

In de vorige secties hebt u uw App Service of Azure-functie geregistreerd om gebruikers te verifiëren. In deze sectie wordt uitgelegd hoe u systeemeigen clients of daemon-apps registreert in Microsoft Entra ID, zodat ze toegang kunnen aanvragen tot API's die worden weergegeven door uw App Service namens gebruikers of zichzelf, zoals in een N-laag-architectuur. Het voltooien van de stappen in deze sectie is niet vereist als u alleen gebruikers wilt verifiëren.

Systeemeigen clienttoepassing

U kunt systeemeigen clients registreren om toegang te vragen tot de API's van uw App Service-app namens een aangemelde gebruiker.

1. Selecteer Microsoft Entra ID in het portalmenu.

2. Selecteer in het linkernavigatievenster App-registraties> Nieuwe registratie.

3. Voer op de pagina Een toepassing registreren een naam in voor uw app-registratie.

4. Selecteer in omleidings-URI de optie Openbare client (mobiel en desktop) en typ de URL <app-url>/.auth/login/aad/callback. Bijvoorbeeld: https://contoso.azurewebsites.net/.auth/login/aad/callback.

5. Selecteer Registreren.

6. Nadat de app-registratie is gemaakt, kopieert u de waarde van de toepassings-id (client).

   Notitie

   Voor een Microsoft Store-toepassing gebruikt u in plaats daarvan de pakket-SID als de URI.

7. Selecteer in het linkernavigatievenster API-machtigingen>Een machtiging>toevoegen Mijn API's.

8. Selecteer de app-registratie die u eerder hebt gemaakt voor uw App Service-app. Als u de app-registratie niet ziet, controleert u of u het user_impersonation bereik hebt toegevoegd in Een app-registratie maken in Microsoft Entra-id voor uw App Service-app.

9. Selecteer onder Gedelegeerde machtigingen user_impersonation en selecteer vervolgens Machtigingen toevoegen.

U hebt nu een systeemeigen clienttoepassing geconfigureerd die namens een gebruiker toegang kan aanvragen tot uw App Service-app.

Daemon-clienttoepassing (service-naar-service-aanroepen)

In een N-tier-architectuur kan uw clienttoepassing een token verkrijgen om een App Service- of Functie-app aan te roepen namens de client-app zelf (niet namens een gebruiker). Dit scenario is handig voor niet-interactieve daemon-toepassingen die taken uitvoeren zonder een aangemelde gebruiker. Er wordt gebruikgemaakt van de standaard-OAuth 2.0-clientreferenties verlenen.

1. Selecteer Microsoft Entra ID in het portalmenu.
2. Selecteer in het linkernavigatievenster App-registraties> Nieuwe registratie.
3. Voer op de pagina Een toepassing registreren een naam in voor uw app-registratie.
4. Voor een daemon-toepassing hebt u geen omleidings-URI nodig, zodat u die leeg kunt houden.
5. Selecteer Registreren.
6. Nadat de app-registratie is gemaakt, kopieert u de waarde van de toepassings-id (client).
7. Selecteer in het linkernavigatievenster Certificaten en geheimen Clientgeheimen>>Nieuw clientgeheim.
8. Voer een beschrijving en vervaldatum in en selecteer Toevoegen.
9. Kopieer in het veld Waarde de waarde van het clientgeheim. Deze wordt niet meer weergegeven wanneer u van deze pagina weg navigeert.

U kunt nu een toegangstoken aanvragen met behulp van de client-id en het clientgeheim door de resource parameter in te stellen op de URI van de toepassings-id van de doel-app. Het resulterende toegangstoken kan vervolgens worden weergegeven aan de doel-app met behulp van de standaard OAuth 2.0-autorisatieheader. App Service-verificatie valideert en gebruikt het token zoals gebruikelijk om aan te geven dat de aanroeper (in dit geval geen gebruiker) is geverifieerd.

Op dit moment kan elke clienttoepassing in uw Microsoft Entra-tenant een toegangstoken aanvragen en verifiëren bij de doel-app. Als u ook autorisatie wilt afdwingen om alleen bepaalde clienttoepassingen toe te staan, moet u een extra configuratie uitvoeren.

1. Definieer een app-rol in het manifest van de app-registratie die de App Service- of Functie-app vertegenwoordigt die u wilt beveiligen.
2. Selecteer api-machtigingen>toevoegen> in de app-registratie die de client vertegenwoordigt die moet worden geautoriseerd.
3. Selecteer de app-registratie die u eerder hebt gemaakt. Als u de app-registratie niet ziet, controleert u of u een app-rol hebt toegevoegd.
4. Selecteer onder Toepassingsmachtigingen de app-rol die u eerder hebt gemaakt en selecteer vervolgens Machtigingen toevoegen.
5. Zorg ervoor dat u Beheerderstoestemming verlenen selecteert om de clienttoepassing toestemming te geven om de machtiging aan te vragen.
6. Net als bij het vorige scenario (voordat er rollen zijn toegevoegd), kunt u nu een toegangstoken aanvragen voor hetzelfde doel resourceen bevat het toegangstoken een roles claim met de app-rollen die zijn geautoriseerd voor de clienttoepassing.
7. In de code van de doel-App Service- of Functie-app kunt u nu valideren dat de verwachte rollen aanwezig zijn in het token (dit wordt niet uitgevoerd door App Service-verificatie). Zie Access-gebruikersclaims voor meer informatie.

U hebt nu een daemon-clienttoepassing geconfigureerd die toegang heeft tot uw App Service-app met behulp van een eigen identiteit.

Aanbevolen procedures

Ongeacht de configuratie die u gebruikt om verificatie in te stellen, houden de volgende aanbevolen procedures uw tenant en toepassingen veiliger:

• Configureer elke App Service-app met een eigen app-registratie in Microsoft Entra ID.
• Geef elke App Service-app zijn eigen machtigingen en toestemming.
• Vermijd het delen van machtigingen tussen omgevingen met behulp van afzonderlijke app-registraties voor afzonderlijke implementatiesites. Wanneer u nieuwe code test, kan deze procedure helpen voorkomen dat problemen van invloed zijn op de productie-app.

Migreren naar Microsoft Graph

Sommige oudere apps zijn mogelijk ook ingesteld met een afhankelijkheid van de afgeschafte Azure AD Graph, die is gepland voor volledige buitengebruikstelling. Uw app-code kan bijvoorbeeld Azure AD Graph hebben genoemd om het groepslidmaatschap te controleren als onderdeel van een autorisatiefilter in een middleware-pijplijn. Apps moeten worden verplaatst naar Microsoft Graph door de richtlijnen van Microsoft Entra ID te volgen als onderdeel van het afschaffingsproces van Azure AD Graph. Als u deze instructies volgt, moet u mogelijk enkele wijzigingen aanbrengen in uw configuratie van App Service-verificatie. Nadat u Microsoft Graph-machtigingen hebt toegevoegd aan uw app-registratie, kunt u het volgende doen:

1. Werk de URL van de verlener bij om het achtervoegsel /v2.0 op te nemen als dit nog niet zo is.

2. Verwijder aanvragen voor Azure AD Graph-machtigingen uit uw aanmeldingsconfiguratie. Welke eigenschappen u wilt wijzigen, is afhankelijk van de versie van de beheer-API die u gebruikt:

   • Als u de V1-API (/authsettings) gebruikt, bevindt dit zich in de additionalLoginParams matrix.
   • Als u de V2-API (/authsettingsV2) gebruikt, bevindt dit zich in de loginParameters matrix.

   U moet bijvoorbeeld een verwijzing naar 'https://graph.windows.net"' verwijderen. Dit omvat de resource parameter (die niet wordt ondersteund door het eindpunt /v2.0) of bereiken die u specifiek aanvraagt bij Azure AD Graph.

   U moet ook de configuratie bijwerken om de nieuwe Microsoft Graph-machtigingen aan te vragen die u hebt ingesteld voor de registratie van de toepassing. U kunt het standaardbereik gebruiken om deze installatie in veel gevallen te vereenvoudigen. Voeg hiervoor een nieuwe aanmeldingsparameter scope=openid profile email https://graph.microsoft.com/.defaulttoe.

Wanneer App Service-verificatie zich probeert aan te melden, worden met deze wijzigingen geen machtigingen meer aangevraagd voor Azure AD Graph en wordt er in plaats daarvan een token voor de Microsoft Graph opgehaald. Elk gebruik van dat token uit uw toepassingscode moet ook worden bijgewerkt volgens de richtlijnen van Microsoft Entra ID.

Volgende stappen

• Overzicht van App Service-verificatie/autorisatie.
• Zelfstudie: Eindgebruikers end-to-end verifiëren en autoriseren in Azure-app Service

• Zelfstudie: Gebruikers verifiëren en autoriseren in een web-app die toegang heeft tot Azure Storage en Microsoft Graph
• Zelfstudie: Eindgebruikers end-to-end verifiëren en autoriseren in Azure-app Service