Delen via

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

  • Artikel

Notitie

Vanaf 1 juni 2024 hebben alle nieuw gemaakte App Service-apps de mogelijkheid om een unieke standaardhostnaam te genereren met behulp van de naamconventie <app-name>-<random-hash>.<region>.azurewebsites.net. Bestaande app-namen blijven ongewijzigd.

Voorbeeld: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Raadpleeg de unieke standaardhostnaam voor App Service-resource voor meer informatie.

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) als verificatieprovider.

Kies een tenant voor uw toepassing en de bijbehorende gebruikers

Voordat uw toepassing gebruikers kan aanmelden, moet u deze eerst registreren in een personeels- of externe tenant. Als u uw app beschikbaar maakt voor werknemers of zakelijke gasten, registreert u uw app in een personeelstenant. Als uw app voor consumenten en zakelijke klanten is, registreert u deze in een externe tenant.

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

  2. Selecteer verificatie in het linkermenu van uw app en selecteer vervolgens Id-provider toevoegen.

  3. Selecteer Op de pagina Een id-provider toevoegen Microsoft als id-provider om u aan te melden bij Microsoft- en Microsoft Entra-identiteiten.

  4. Selecteer voor tenanttype personeelsconfiguratie (huidige tenant) voor werknemers en zakelijke gasten of selecteer externe configuratie voor consumenten en zakelijke klanten.

De app-registratie kiezen

De functie App Service-verificatie kan automatisch een app-registratie voor u maken of u kunt een registratie gebruiken die u of een directorybeheerder afzonderlijk hebt gemaakt.

Maak automatisch een nieuwe app-registratie, tenzij u een app-registratie afzonderlijk moet maken. U kunt de app-registratie later aanpassen in het Microsoft Entra-beheercentrum .

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.

Maak en gebruik een nieuwe app-registratie of gebruik een bestaande registratie die afzonderlijk is gemaakt.

Optie 1: Een nieuwe app-registratie maken en gebruiken

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

Notitie

De optie voor het automatisch maken van een nieuwe registratie is niet beschikbaar voor overheidsclouds. Definieer in plaats daarvan afzonderlijk een registratie.

Voer de naam in voor de nieuwe app-registratie.

Selecteer het type ondersteund account:

  • Huidige tenant : één tenant. Alleen accounts in deze organisatiemap. Alle gebruikers- en gastaccounts in uw map kunnen gebruikmaken van uw toepassing of API. Gebruik deze optie als uw doelgroep zich binnen uw organisatie bevindt.
  • Elke Microsoft Entra-map - Multitenant. Accounts in elke organisatiemap. Alle gebruikers met een werk- of schoolaccount van Microsoft kunnen uw toepassing of API gebruiken. Dit omvat scholen en bedrijven die Gebruikmaken van Office 365. Gebruik deze optie als uw doelgroep zakelijke of educatieve klanten is en multitenancy mogelijk wilt maken.
  • Alle Microsoft Entra-directory's en persoonlijke Microsoft-accounts. Accounts in elke organisatiedirectory en persoonlijke Microsoft-accounts (bijvoorbeeld Skype, Xbox). Alle gebruikers met een werk-, school- of persoonlijk account van Microsoft kunnen uw toepassing of API gebruiken. Het omvat scholen en bedrijven die Gebruikmaken van Office 365 en persoonlijke accounts die worden gebruikt om u aan te melden bij services zoals Xbox en Skype. Gebruik deze optie om de breedste set Microsoft-identiteiten te richten en multitenancy in te schakelen.
  • Alleen persoonlijke Microsoft-accounts. Persoonlijke accounts die worden gebruikt om u aan te melden bij services zoals Xbox en Skype. Gebruik deze optie om de breedste set Microsoft-identiteiten te targeten.

U kunt desgewenst de naam van de registratie of de ondersteunde accounttypen wijzigen.

Er wordt een clientgeheim gemaakt 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.

Optie 2: Gebruik een bestaande registratie die afzonderlijk is gemaakt

Ofwel:

  • Selecteer Een bestaande app-registratie in deze map en selecteer een app-registratie in de vervolgkeuzelijst.
  • Selecteer Geef de details op van een bestaande app-registratie en geef het volgende op:
    • Id van toepassing (client).
    • Clientgeheim (aanbevolen). Een geheime waarde die door de toepassing wordt gebruikt om de identiteit te bewijzen bij het aanvragen van een token. Deze waarde wordt opgeslagen in de configuratie van uw app als een site-sticky toepassingsinstelling met de naam MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Als het clientgeheim niet is ingesteld, gebruiken aanmeldingsbewerkingen van de service de impliciete toekenningsstroom OAuth 2.0. Dit wordt niet aanbevolen.
    • Url van verlener, die de vorm <authentication-endpoint>/<tenant-id>/v2.0heeft. Vervang door <authentication-endpoint> de verificatie-eindpuntwaarde die specifiek is voor de cloudomgeving. Een personeelstenant in globale Azure gebruikt bijvoorbeeld 'https://sts.windows.net" als verificatie-eindpunt.

Als u handmatig een app-registratie in een personeelstenant moet maken, volgt u de quickstart voor het registreren van een toepassing . Wanneer u het registratieproces doorloopt, moet u de waarden voor de toepassings-id (client) en clientgeheim noteren.

Tijdens het registratieproces selecteert u in de sectie Omleidings-URI's het web voor platform en typt <app-url>/.auth/login/aad/callbacku . Bijvoorbeeld: https://contoso.azurewebsites.net/.auth/login/aad/callback.

Pas na het maken de app-registratie aan:

  1. 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 multitenant-app 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.

  2. Selecteer Een bereik toevoegen.

    1. Voer in bereiknaam user_impersonation in.
    2. In Wie kan toestemming geven, selecteert u Beheerders 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.

  3. (Aanbevolen) 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.

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

Aanvullende controles configureren

Configureer aanvullende controles, waarmee wordt bepaald welke aanvragen toegang hebben tot uw toepassing. U kunt dit gedrag nu aanpassen of deze instellingen later aanpassen vanuit het hoofdscherm voor verificatie door Bewerken naast verificatie-instellingen te kiezen.

Kies voor de vereiste clienttoepassing of u het volgende wilt doen:

  • Alleen aanvragen van deze toepassing zelf toestaan
  • Aanvragen van specifieke clienttoepassingen toestaan
  • Aanvragen van een toepassing toestaan (niet aanbevolen)

Kies voor identiteitsvereiste of u het volgende wilt doen:

  • Aanvragen van elke identiteit toestaan
  • Aanvragen van specifieke identiteiten toestaan

Kies voor tenantvereiste of u het volgende wilt doen:

  • Alleen aanvragen van de verlenertenant toestaan
  • Aanvragen van specifieke tenants toestaan
  • Standaardbeperkingen gebruiken op basis van verlener

Uw app moet mogelijk nog steeds aanvullende autorisatiebeslissingen nemen in code. Zie Een ingebouwd autorisatiebeleid gebruiken voor meer informatie.

Verificatie-instellingen configureren

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.

Als u de toegang wilt beperken, moet u beslissen of u het volgende wilt doen:

  • Verificatie vereisen
  • Niet-geverifieerde toegang toestaan

Voor niet-geverifieerde aanvragen

  • HTTP 302 Gevonden omleiding: aanbevolen voor websites
  • HTTP 401 Niet geautoriseerd: aanbevolen voor API's
  • HTTP 403 Verboden
  • HTTP 404 Niet gevonden

Selecteer tokenarchief (aanbevolen). In het tokenarchief worden tokens voor uw toepassing verzameld, opgeslagen en vernieuwd. U kunt dit later uitschakelen als uw app geen tokens nodig heeft of als u de prestaties wilt optimaliseren.

De id-provider toevoegen

Als u de personeelsconfiguratie hebt geselecteerd, kunt u Volgende selecteren : Machtigingen en eventuele Microsoft Graph-machtigingen toevoegen die nodig zijn voor de toepassing. Deze worden toegevoegd aan de app-registratie, maar u kunt ze later ook wijzigen. Als u externe configuratie hebt geselecteerd, kunt u later Microsoft Graph-machtigingen toevoegen.

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.

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.

Tip

Toepassingen met meerdere tenants moeten de verlener en tenant-id van de aanvraag valideren als onderdeel van dit proces om ervoor te zorgen dat de waarden zijn toegestaan. Wanneer App Service-verificatie is geconfigureerd voor een scenario met meerdere tenants, wordt niet gevalideerd van welke tenant de aanvraag afkomstig is. Een app moet mogelijk worden beperkt tot specifieke tenants, afhankelijk van of de organisatie zich heeft geregistreerd voor de service, bijvoorbeeld. Zie de richtlijnen voor het Microsoft Identity Platform voor meerdere tenants.

Validaties uitvoeren vanuit toepassingscode

Wanneer u autorisatiecontroles uitvoert in uw app-code, kunt u de claimgegevens gebruiken 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": []
            }
        }
    }
}
Eigenschappen Beschrijving
defaultAuthorizationPolicy Een groepering van vereisten waaraan moet worden voldaan om toegang te krijgen tot de app. Toegang wordt verleend op basis van een logische AND waarde voor elk van de geconfigureerde eigenschappen. Wanneer allowedApplications en allowedPrincipals beide zijn geconfigureerd, moet de binnenkomende aanvraag voldoen aan beide vereisten om te worden geaccepteerd.
allowedApplications Een acceptatielijst met client-id's van tekenreekstoepassingen die de clientresource vertegenwoordigen die in de app wordt aangeroepen. Wanneer deze eigenschap is geconfigureerd als een niet-mpige matrix, worden alleen tokens geaccepteerd die zijn verkregen door een toepassing die is opgegeven in de lijst.

Met dit beleid wordt de appid of azp claim van het binnenkomende token geëvalueerd. Dit moet een toegangstoken zijn. Zie de referentie voor claims van het Microsoft Identity Platform.
allowedPrincipals Een groep controles die bepalen of de principal die wordt vertegenwoordigd door de binnenkomende aanvraag, toegang heeft tot de app. Tevredenheid is gebaseerd op een logische OR waarde ten opzichte van allowedPrincipals de geconfigureerde eigenschappen.
identities (onder allowedPrincipals) Een acceptatielijst met tekenreeksobject-id's die gebruikers of toepassingen vertegenwoordigen die toegang hebben. Wanneer deze eigenschap is geconfigureerd als een niet-mpige matrix, kan aan de allowedPrincipals vereiste worden voldaan als de gebruiker of toepassing die wordt vertegenwoordigd door de aanvraag is opgegeven in de lijst. Er geldt een limiet van 500 tekens in de lijst met identiteiten.

Met dit beleid wordt de oid claim van het binnenkomende token geëvalueerd. Zie de referentie voor claims van het Microsoft Identity Platform.

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 van maximaal 10 tenant-id's (bijvoorbeeld aaaabbbb-0000-cccc-1111-ddd2222e) 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, zodat ze toegang kunnen aanvragen tot API's die door uw App Service worden weergegeven 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 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 de app-registratie.

  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 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.
  • 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 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.

Volgende stappen