Delen via

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

  • Artikel

Notitie

Vanaf 1 juni 2024 kunnen nieuw gemaakte App Service-apps een unieke standaardhostnaam genereren die gebruikmaakt van de naamconventie <app-name>-<random-hash>.<region>.azurewebsites.net. Bestaande app-namen blijven ongewijzigd. Voorbeeld:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Zie 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 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 in het linkermenu van uw app instellingenverificatie> en selecteer vervolgens Id-provider toevoegen.

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

  4. Selecteer onder Kies een tenant voor uw toepassing en de bijbehorende gebruikers de optie Workforce-configuratie (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 adreslijstbeheerder afzonderlijk maakt.

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.

U kunt een nieuwe app-registratie (optie 1) maken en gebruiken of een bestaande registratie afzonderlijk maken (optie 2).

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 nadat u deze hebt gemaakt.

Notitie

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

  1. Selecteer Nieuwe app-registratie maken.

  2. Voer de naam in voor de nieuwe app-registratie.

  3. 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. Deze accounts omvatten 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. Als u het geheim in Azure Key Vault wilt beheren, kunt u deze instelling later bijwerken om Key Vault-verwijzingen te gebruiken.

Optie 2: Gebruik een bestaande registratie die afzonderlijk is gemaakt

Selecteer een van de volgende opties:

  • Kies een bestaande app-registratie in deze map en selecteer een app-registratie in de vervolgkeuzelijst.

  • Geef de details op van een bestaande app-registratie en geef het volgende op:

    • Toepassings-id (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, raadpleegt u Een toepassing registreren bij het Microsoft Identity Platform. 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 een resource, waarmee tokens kunnen worden aangevraagd die toegang verlenen. De waarde is een 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 aanbevolen beveiligingsprocedures voor toepassingseigenschappen in Microsoft Entra ID 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 de naam van het toestemmingsbereik in. Voer een beschrijving 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. Nadat u van deze pagina bent verwijderd, wordt deze niet meer weergegeven.

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

Aanvullende controles configureren

Aanvullende controles bepalen 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 andere 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. 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 Verificatiestroom voor meer informatie.

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 gedrag 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 machtigingen 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 App-verificatie toevoegen aan uw web-app 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

Standaard verwerkt App Service-verificatie alleen verificatie. Het bepaalt of de beller is wie ze zeggen dat ze zijn. Autorisatie, het bepalen of die beller toegang moet hebben tot een bepaalde resource, is een stap verder dan verificatie. Zie De basisprincipes van autorisatie voor meer informatie.

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

Tip

Multitenant-toepassingen 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, op basis van of de organisatie zich bijvoorbeeld heeft geregistreerd voor de service. Zie Uw code bijwerken om meerdere verlenerwaarden te verwerken.

Validaties uitvoeren vanuit toepassingscode

Wanneer u autorisatiecontroles uitvoert in uw app-code, kunt u de claimgegevens gebruiken die App Service-verificatie beschikbaar maakt. Zie Access-gebruikersclaims in app-code voor meer informatie.

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 in de tenant toegang krijgen tot de toepassing. Deze aanpak is prima voor veel toepassingen. Sommige toepassingen moeten de toegang 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 met behulp van 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 groep 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 worden 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 nettoladingclaims.
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 nettoladingclaims.

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 aaaabbbb-0000-cccc-1111-dddd2222eeee.

Deze instelling kan 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 voor true of 1 vereist dat het binnenkomende token een oid claim bevat. Als allowedPrincipals.identities deze instelling is geconfigureerd, wordt deze instelling genegeerd en behandeld als waar omdat de oid claim wordt 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. Ze kunnen toegang aanvragen tot API's die door uw App Service worden weergegeven namens gebruikers of zichzelf, zoals in een architectuur met N-lagen. Als u alleen gebruikers wilt verifiëren, zijn de stappen in deze sectie niet vereist.

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 Beheren> App-registraties in het linkernavigatievenster en selecteer vervolgens Nieuwe registratie.

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

  4. Selecteer in omleidings-URI openbare client/systeemeigen (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 api-machtigingen beheren>in het linkernavigatievenster. Selecteer vervolgens 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, moet u ervoor zorgen dat u het user_impersonation bereik toevoegt in de app-registratie.

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

U hebt 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. Zie Microsoft Identity Platform en de OAuth 2.0-clientreferentiestroom voor meer informatie.

  1. Selecteer Microsoft Entra ID in het menu van Azure Portal.
  2. Selecteer Beheren> App-registraties> Nieuwe registratie in het linkernavigatievenster.
  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 certificaten en geheimen beheren>in het linkernavigatievenster. Selecteer vervolgens Clientgeheimen>Nieuw clientgeheim.
  8. Voer een beschrijving en vervaldatum in en selecteer Toevoegen.
  9. Kopieer in het veld Waarde de waarde van het clientgeheim. Nadat u van deze pagina bent verwijderd, wordt deze niet meer weergegeven.

U kunt nu een toegangstoken aanvragen met behulp van de client-id en het clientgeheim. Stel de resource parameter in 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 beller is geverifieerd. In dit geval is de aanroeper een toepassing, niet een gebruiker.

Met deze methode 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 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 in de app-registratie die de client vertegenwoordigt die moet worden geautoriseerd DE API-machtigingen>Een machtiging>toevoegen Mijn API's.

  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. Selecteer vervolgens Machtigingen toevoegen.

  5. Zorg ervoor dat u Beheerderstoestemming verlenen selecteert om de clienttoepassing toestemming te geven om de machtiging aan te vragen.

    Net als bij het vorige scenario (voordat er rollen werden 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.

In de code van de doel-App Service- of Functie-app kunt u nu valideren dat de verwachte rollen aanwezig zijn in het token. App Service-verificatie voert deze validatie niet uit. Zie Access-gebruikersclaims voor meer informatie.

U hebt 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. Gebruik 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 kunnen worden ingesteld met een afhankelijkheid van de afgeschafte Azure AD Graph, die is gepland voor volledige buitengebruikstelling. Uw app-code kan bijvoorbeeld Azure AD Graph aanroepen om het groepslidmaatschap te controleren als onderdeel van een autorisatiefilter in een middleware-pijplijn. Apps moeten worden verplaatst naar Microsoft Graph. Zie Uw apps migreren van Azure AD Graph naar Microsoft Graph voor meer informatie.

Tijdens deze migratie 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 /v2.0 achtervoegsel 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 deze instelling zich in de additionalLoginParams matrix.
    • Als u de V2-API (/authsettingsV2) gebruikt, bevindt deze instelling zich in de loginParameters matrix.

    U moet bijvoorbeeld een verwijzing naar https://graph.windows.netverwijderen. Deze wijziging omvat de resource parameter, die niet wordt ondersteund door het /v2.0 eindpunt, of bereiken die u specifiek aanvraagt vanuit 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. In plaats daarvan krijgt het een token voor Microsoft Graph. Elk gebruik van dat token vanuit uw toepassingscode moet ook worden bijgewerkt, zoals beschreven in Uw apps migreren van Azure AD Graph naar Microsoft Graph.

Volgende stappen