Partager via

Configurer votre application App Service ou Azure Functions pour utiliser une connexion de compte Microsoft

  • Article

Remarque

À compter du 1er juin 2024, les applications App Service nouvellement créées peuvent générer un nom d’hôte par défaut unique qui utilise la convention d’affectation de noms <app-name>-<random-hash>.<region>.azurewebsites.net. Les noms d’application existants restent inchangés. Par exemple :

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Pour plus d’informations, consultez Nom d’hôte par défaut unique pour les ressources App Service.

Sélectionnez un autre fournisseur d’authentification pour y accéder.

Cet article explique comment configurer l’authentification pour Azure App Service ou Azure Functions afin que votre application utilise la Plateforme d’identités Microsoft (Microsoft Entra) comme fournisseur d’authentification pour la connexion des utilisateurs.

Choisir un locataire pour votre application et ses utilisateurs

Pour que votre application puisse connecter des utilisateurs, vous devez d’abord l’inscrire dans un locataire de main-d’œuvre ou un locataire externe. Si votre application est destinée aux employés ou à des invités professionnels, inscrivez-la dans un locataire de main-d’œuvre. Si votre application est destinée aux consommateurs ou aux clients professionnels, inscrivez-la dans un locataire externe.

  1. Connectez-vous au Portail Azure et accédez à votre application.

  2. Dans le menu de gauche de votre application, sélectionnez Paramètres>Authentification, puis Ajouter un fournisseur d’identité.

  3. Dans la page Ajouter un fournisseur d’identité, sélectionnez Microsoft en tant que fournisseur d’identité pour vous connecter aux identités Microsoft et Microsoft Entra.

  4. Sous Choisir un locataire pour votre application et ses utilisateurs, sélectionnez Configuration de main-d’œuvre (locataire actuel) pour les employés et les invités professionnels, ou sélectionnez Configuration externe pour les consommateurs et les clients professionnels.

Choisir l’inscription d’application

La fonctionnalité d’authentification App Service peut automatiquement créer une inscription d’application à votre place, ou vous pouvez utiliser une inscription que vous ou un administrateur d’annuaire avez créée séparément.

Créez automatiquement une inscription d’application, sauf si vous devez créer une inscription d’application séparément. Si vous le souhaitez, vous pouvez personnaliser l’inscription d’application dans le centre d’administration Microsoft Entra ultérieurement.

Les situations suivantes sont les cas les plus courants d’utilisation d’une inscription d’application existante :

  • Votre compte ne dispose pas des autorisations nécessaires pour créer des inscriptions d’applications dans votre locataire Microsoft Entra.
  • Vous souhaitez utiliser une inscription d’application provenant d’un locataire Microsoft Entra différent de celui où se trouve l’application App Service.
  • L’option permettant de créer une nouvelle inscription n’est pas disponible pour les clouds gouvernementaux.

Vous pouvez créer et utiliser une nouvelle inscription d’application (option 1) ou utiliser une inscription existante créée séparément (option 2).

Option 1 : Créer une inscription d’application automatiquement

Utilisez cette option, sauf si vous devez créer une inscription d’application séparément. Après avoir créé l’inscription d’application, vous pouvez la personnaliser dans Microsoft Entra.

Remarque

L’option permettant de créer une inscription n’est pas disponible pour les clouds gouvernementaux. Au lieu de cela, définissez une inscription séparément.

  1. Sélectionnez Créer une inscription d’application.

  2. Entrez le Nom de la nouvelle inscription d’application.

  3. Sélectionnez le Type de compte pris en charge :

    • Locataire actuel - Monolocataire. Comptes dans cet annuaire organisationnel uniquement. Tous les comptes d’utilisateur et d’invité de votre répertoire peuvent utiliser votre application ou votre API. Utilisez cette option si votre audience cible est interne à votre organisation.
    • N’importe quel répertoire Microsoft Entra - Multilocataire. Comptes dans un annuaire organisationnel Tous les utilisateurs avec un compte professionnel ou scolaire Microsoft peuvent utiliser votre application ou API. Ces comptes incluent les établissements scolaires et les entreprises qui utilisent Office 365. Utilisez cette option si votre audience cible est constituée de clients d’entreprise ou du secteur éducatif, et pour activer l’architecture multilocataire.
    • N’importe quels répertoire Azure AD et comptes Microsoft personnels. Comptes dans un répertoire organisationnel et comptes Microsoft personnels (par exemple Skype, Xbox). Tous les utilisateurs avec un compte professionnel ou scolaire, ou un compte personnel Microsoft, peuvent utiliser votre application ou API. Ceci inclut les établissements scolaires et les entreprises qui utilisent Office 365, ainsi que les comptes personnels utilisés pour se connecter à des services tels que Xbox et Skype. Utilisez cette option pour cibler l’ensemble le plus large d’identités Microsoft et pour activer l’architecture multilocataire.
    • Comptes Microsoft personnels uniquement. Comptes personnels utilisés pour se connecter à des services tels que Xbox et Skype. Utilisez cette option pour cibler l’ensemble le plus large d’identités Microsoft.

Si vous le souhaitez, vous pouvez modifier le nom de l’inscription ou les types de comptes pris en charge ultérieurement.

La clé secrète client est créée sous la forme d’un paramètre d’application d’emplacement fixe nommé MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Si vous souhaitez gérer le secret dans Azure Key Vault, vous pouvez mettre à jour ce paramètre ultérieurement pour utiliser des références Key Vault.

Option 2 : Utiliser une inscription existante créée séparément

Sélectionnez l’une des valeurs suivantes :

  • Choisir une inscription d’application existante dans cet annuaire et sélectionnez une inscription d’application dans la liste déroulante.

  • Fournir les détails d’une inscription d’application existante et fournissez les éléments suivants :

    • ID d’application (client).
    • Clé secrète client (recommandé). Valeur secrète utilisée par l’application pour prouver son identité lors de la demande d’un jeton. Cette valeur est enregistrée dans la configuration de votre application sous la forme d’un paramètre d’application d’emplacement fixe nommé MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Si la clé secrète client n’est pas définie, les opérations de connexion du service utilisent le flux d’octroi implicite OAuth 2.0, qui n’est pas recommandé.
    • URL de l’émetteur, sous la forme <authentication-endpoint>/<tenant-id>/v2.0. Remplacez <authentication-endpoint> par la valeur du point de terminaison d’authentification spécifique à l’environnement cloud. Par exemple, un locataire de main-d’œuvre dans Azure global utiliserait «https://sts.windows.net" comme point de terminaison d’authentification.

Si vous avez besoin de créer manuellement une inscription d’application dans un locataire de main-d’œuvre, veuillez consulter Inscrire une application avec la Plateforme d’identités Microsoft. Lorsque vous passez par le processus d’inscription, veillez à noter l’ID d’application (client) et les valeurs de la clé secrète client.

Au cours du processus d’inscription, dans la section URI de redirection, sélectionnez Web pour la plateforme et tapez <app-url>/.auth/login/aad/callback. Par exemple : https://contoso.azurewebsites.net/.auth/login/aad/callback.

Après la création, modifiez l’inscription d’application :

  1. Dans le volet de navigation de gauche, sélectionnez Exposer une API>Ajouter>Enregistrer. Cette valeur identifie de façon unique l’application lorsqu’elle est utilisée en tant que ressource, ce qui permet de demander des jetons qui accordent l’accès. La valeur est un préfixe pour les étendues que vous créez.

    Pour une application à locataire unique, vous pouvez utiliser la valeur par défaut, qui se présente sous la forme api://<application-client-id>. Vous pouvez également spécifier un URI plus lisible comme https://contoso.com/api basé sur l’un des domaines vérifiés pour votre locataire. Pour une application mutualisée, vous devez fournir un URI personnalisé. Si vous souhaitez en savoir plus sur les formats acceptés pour les URI d’ID d’application, veuillez consulter Meilleures pratiques de sécurité pour les propriétés d’application dans Microsoft Entra ID.

  2. sélectionner Ajouter une étendue.

    1. Dans Nom de l’étendue, entrez user_impersonation.
    2. Dans Qui peut donner son consentement, sélectionnez Administrateurs et utilisateurs si vous souhaitez autoriser les utilisateurs à consentir à cette étendue.
    3. Entrez le nom de l’étendue de consentement. Entrez la description que vous souhaitez montrer aux utilisateurs sur la page de consentement. Par exemple, entrez Accéder à <nom-application> .
    4. Sélectionnez Ajouter une étendue.

  3. (Recommandé) Pour créer une clé secrète client :

    1. Dans le volet de navigation de gauche, sélectionnez Certificats et secrets>Clés secrètes de client>Nouvelle clé secrète client.
    2. Entrez une description et une expiration, puis sélectionnez Ajouter.
    3. Dans le champ Valeur, copiez la valeur de la clé secrète client. Une fois que vous quittez cette page, elle n’apparaît plus.

  4. (Facultatif) Pour ajouter plusieurs URL de réponse, sélectionnez Authentification.

Configurer des vérifications supplémentaires

Les vérifications supplémentaires permettent d’identifier les demandes autorisées à accéder à votre application. Vous pouvez personnaliser ce comportement maintenant ou ajuster ces paramètres ultérieurement à partir de l’écran principal Authentification en choisissant Modifier en regard de Paramètres d’authentification.

Pour Besoins de l’application cliente, choisissez s’il faut :

  • Autoriser uniquement les demandes de l’application à proprement parler
  • Autoriser les demandes provenant d’applications clientes spécifiques
  • Autoriser les demandes de n’importe quelle application (non recommandé)

Pour Exigence d’identité, choisissez s’il faut :

  • Autoriser les demandes de n’importe quelle identité
  • Autoriser les demandes d’identités spécifiques

Pour Exigence de locataire, choisissez s’il faut :

  • Autoriser uniquement les demandes du locataire émetteur
  • Autoriser les demandes de locataires spécifiques
  • Utiliser des restrictions par défaut basées sur l’émetteur

Votre application peut encore avoir besoin de prendre d’autres décisions d’autorisation dans le code. Pour plus d’informations, consultez Utiliser une stratégie d’autorisation intégrée.

Configurer les paramètres d’authentification

Ces options déterminent la façon dont votre application répond aux demandes non authentifiées. Les sélections par défaut redirigent toutes les demandes pour se connecter avec ce nouveau fournisseur. Vous pouvez modifier ce comportement maintenant ou ajuster ces paramètres ultérieurement à partir de l’écran principal Authentification en choisissant Modifier en regard de Paramètres d’authentification. Pour plus d’informations, consultez Flux d’authentification.

Pour Restreindre l’accès, choisissez s’il faut :

  • Exiger l’authentification
  • Autoriser l’accès non authentifié

Pour les requêtes non authentifiées

  • HTTP 302 Redirection trouvée : recommandé pour les sites web
  • HTTP 401 Non autorisé : recommandé pour les API
  • HTTP 403 Interdit
  • HTTP 404 (introuvable)

Sélectionnez un magasin de jetons (recommandé). Le magasin de jetons collecte, stocke et actualise les jetons pour votre application. Vous pouvez désactiver ce comportement par la suite si votre application n’a pas besoin de jetons ou si vous devez optimiser les performances.

Ajouter le fournisseur d’identité

Si vous avez choisi la configuration de main-d’œuvre, sélectionnez Suivant : autorisations et ajoutez les autorisations de Microsoft Graph nécessaires à l’application. Ces autorisations sont ajoutées à l’inscription de l’application, mais vous pouvez également les modifier ultérieurement. Si vous avez sélectionné la configuration externe, vous pourrez ajouter des autorisations Microsoft Graph ultérieurement.

  • Sélectionnez Ajouter.

Vous êtes maintenant prêt à utiliser la plateforme d’identités Microsoft pour l’authentification dans votre application. Le fournisseur est répertorié sur l’écran Authentification. À partir de là, vous pouvez modifier ou supprimer cette configuration de fournisseur.

Pour obtenir un exemple de configuration de la connexion Microsoft Entra pour une application web qui accède à Stockage Azure et à Microsoft Graph, veuillez consulter Ajouter l’authentification d’application à votre application web.

Autoriser des requêtes

Par défaut, l’authentification App Service gère uniquement l’authentification. Elle détermine si l’appelant est bien la personne qu’elle dit être. L’autorisation, qui détermine si cet appelant doit avoir accès à une ressource, est une étape qui va au-delà de l’authentification. Si vous souhaitez en savoir plus, veuillez consulter Notions de base des autorisations.

Votre application peut prendre des décisions d’autorisation relatives au code. L’authentification App Service propose des vérifications intégrées qui peuvent vous être utiles, mais elles risquent de ne pas suffire à elles seules à couvrir les besoins en autorisation de votre application.

Conseil

Les applications multilocataires doivent valider l’émetteur et l’ID de locataire de la requête dans le cadre de ce processus pour s’assurer que les valeurs sont autorisées. Lorsque l’authentification App Service est configurée pour un scénario multilocataire, elle ne valide pas le locataire d’où provient la requête. Une application peut avoir besoin d’être limitée à certains locataires, selon que l’organisation s’est inscrite ou non au service, par exemple. Veuillez consulter Mettre à jour votre code pour gérer plusieurs valeurs d’émetteur.

Effectuer des validations à partir du code d’application

Lorsque vous effectuez des vérifications d’autorisation dans le code de votre application, vous pouvez utiliser les informations de revendications que l’authentification App Service met à disposition. Si vous souhaitez en savoir plus, veuillez consulter Accéder aux revendications d’utilisateurs dans le code d’application.

L’en-tête injecté x-ms-client-principal contient un objet JSON codé en Base64 avec les revendications déclarées concernant l’appelant. Par défaut, ces revendications passent par un mappage de revendications. Il est donc possible que les noms des revendications ne correspondent pas toujours à ce que vous voyez dans le jeton. Par exemple, la revendication tid est mappée à http://schemas.microsoft.com/identity/claims/tenantid à la place.

Vous pouvez également travailler directement avec le jeton d’accès sous-jacent à partir de l’en-tête injecté x-ms-token-aad-access-token.

Utiliser une stratégie d’autorisation intégrée

L’inscription de l’application créée authentifie les requêtes entrantes pour votre locataire Microsoft Entra. Par défaut, cela permet aussi à quiconque au sein du locataire d’accéder à l’application. Cette approche adaptée à un grand nombre d’applications. Certaines applications doivent restreindre davantage l’accès en prenant des décisions d’autorisation. Votre code d’application est souvent le meilleur endroit pour gérer une logique d’autorisation personnalisée. Toutefois, pour les scénarios courants, la plateforme d’identité Microsoft fournit des vérifications intégrées que vous pouvez utiliser pour limiter l’accès.

Cette section montre comment activer les vérifications intégrées à l’aide de l’API d’authentification App Service V2. Actuellement, le seul moyen de configurer ces vérifications intégrées est d’utiliser des modèles Azure Resource Manager ou l’API REST.

Dans l’objet API, la configuration du fournisseur d’identité Microsoft Entra comporte une section validation qui peut inclure un objet defaultAuthorizationPolicy comme dans la structure suivante :

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Propriété Description
defaultAuthorizationPolicy Ensemble de conditions devant être remplies pour accéder à l’application. L’accès est accordé en fonction d’une logique AND sur chacune de ses propriétés configurées. Lorsque allowedApplications et allowedPrincipals sont tous les deux configurés, la demande entrante doit remplir les deux conditions pour être acceptée.
allowedApplications Liste d’autorisation des ID de client d’application (sous forme de chaînes) qui représentent la ressource client appelant l’application. Lorsque cette propriété est configurée en tant que tableau non vide, seuls les jetons obtenus par une application spécifiée dans la liste sont acceptés.

Cette stratégie évalue la revendication appid ou azp du jeton entrant, qui doit être un jeton d’accès. Veuillez consulter Revendications de charge utile.
allowedPrincipals Ensemble de vérifications qui déterminent si le principal représenté par la demande entrante peut accéder à l’application. La satisfaction de la condition allowedPrincipals est basée sur une logique OR sur ses propriétés configurées.
identities (sous allowedPrincipals) Liste d’autorisation des ID d’objet sous forme de chaînes représentant les utilisateurs ou les applications qui ont accès. Lorsque cette propriété est configurée en tant que tableau non vide, la condition allowedPrincipals peut être remplie si l’utilisateur ou l’application représenté par la demande est spécifié dans la liste. Il existe une limite de 500 caractères dans la liste des identités.

Cette stratégie évalue la revendication oid du jeton entrant. Veuillez consulter Revendications de charge utile.

De même, certaines vérifications peuvent être configurées via un paramètre d’application, quelle que soit la version d’API utilisée. Le paramètre d’application WEBSITE_AUTH_AAD_ALLOWED_TENANTS peut être configuré avec une liste séparée par des virgules d’un maximum de 10 ID de locataire, par exemple aaaabbbb-0000-cccc-1111-dddd2222eeee.

Ce paramètre peut exiger que le jeton entrant provienne de l’un des locataires spécifiés, comme l’indique la revendication tid. Le paramètre d’application WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL peut être configuré sur true ou 1 pour exiger que le jeton entrant contienne une revendication oid. Si allowedPrincipals.identities a été configuré, ce paramètre est ignoré et considéré comme ayant la valeur true, car la revendication oid est vérifiée par rapport à cette liste d’identités fournie.

Les demandes qui échouent à ces vérifications intégrées reçoivent une réponse HTTP 403 Forbidden.

Configurer des applications clientes pour qu’elles accèdent à votre application App Service

Dans les sections précédentes, vous avez inscrit votre application App Service ou Azure Functions pour authentifier les utilisateurs. Cette section explique comment inscrire des clients natifs ou des applications démon dans Microsoft Entra. Ils peuvent demander l’accès aux API exposées par votre App Service pour le compte des utilisateurs ou d’eux-mêmes, comme dans une architecture multiniveau. Si vous souhaitez uniquement authentifier les utilisateurs, il n’est pas nécessaire de suivre les étapes de cette section.

Application cliente native

Vous pouvez inscrire des clients natifs afin qu’ils puissent demander l’accès aux API de votre application App Service pour le compte d’un utilisateur connecté.

  1. Dans le menu du portail, sélectionnez Microsoft Entra ID.

  2. Dans le volet de navigation de gauche, sélectionnez Gérer>Inscriptions d’applications, puis Nouvelle inscription.

  3. Sur la page Inscrire une application, entrez un Nom pour votre inscription d'application.

  4. Dans URI de redirection, sélectionnez Client public/natif (mobile et bureau), puis tapez l’URL <app-url>/.auth/login/aad/callback. Par exemple : https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Sélectionnez Inscription.

  6. Une fois l’inscription d’application créée, copiez la valeur de l’ID d’application (client) .

    Notes

    Pour une application Microsoft Store, utilisez plutôt le SID de package en guise d’URI.

  7. Dans le volet de navigation de gauche, sélectionnez Gérer>Autorisations d’API. Sélectionnez ensuite Ajouter une autorisation>Mes API.

  8. Sélectionnez l’inscription d'application que vous avez créée précédemment pour votre application App Service. Si vous ne voyez pas l’inscription d’application, veillez à ajouter l’étendue user_impersonation à ladite inscription.

  9. Sous Autorisations déléguées, sélectionnez user_impersonation, puis Ajouter des autorisations.

Vous avez configuré une application cliente native qui peut demander l’accès à votre application App Service pour le compte d’un utilisateur.

Application cliente démon (appels de service à service)

Dans une architecture multiniveau, votre application cliente peut acquérir un jeton pour appeler une application App Service ou de fonction au nom de l’application cliente elle-même, et pas au nom d’un utilisateur. Ce scénario est utile pour les applications de démon non interactives qui effectuent des tâches sans utilisateur connecté. Il utilise l’octroi d’informations d’identification du client OAuth 2.0 standard. Pour plus d’informations, voir Plateforme d’identités Microsoft et flux d’informations d’identification du client OAuth 2.0.

  1. Dans le menu du portail Azure, sélectionnez Microsoft Entra ID.
  2. Dans le volet de navigation de gauche, sélectionnez Gérer>Inscriptions d’applications>Nouvelle inscription.
  3. Sur la page Inscrire une application, entrez un Nom pour votre inscription d'application.
  4. Pour une application démon, vous n’avez pas besoin d’un URI de redirection. Vous pouvez donc conserver cette zone vide.
  5. Sélectionnez Inscription.
  6. Une fois l’inscription d’application créée, copiez la valeur de l’ID d’application (client) .
  7. Dans le volet de navigation de gauche, sélectionnez Gérer>Certificats et secrets. Sélectionnez ensuite Clés secrètes client>Nouvelle clé secrète client.
  8. Entrez une description et une expiration, puis sélectionnez Ajouter.
  9. Dans le champ Valeur, copiez la valeur de la clé secrète client. Une fois que vous quittez cette page, elle n’apparaît plus.

Vous pouvez maintenant demander un jeton d’accès en utilisant l’ID client et la clé secrète client. Définissez le paramètre resource en lui attribuant l’URI d’ID d’application de l’application cible. Le jeton d’accès obtenu peut ensuite être présenté à l’application cible à l’aide de l’en-tête d’autorisation OAuth 2.0 standard. L’authentification App Service valide et utilise le jeton comme d’habitude pour désormais indiquer que l’appelant est authentifié. Dans ce cas, l’appelant est une application, et non un utilisateur.

Cette approche permet à n’importe quelle application cliente de votre locataire Microsoft Entra de demander un jeton d’accès et de s’authentifier auprès de l’application cible. Si vous souhaitez également appliquer un autorisation pour autoriser seules certaines applications clientes, vous devez effectuer une configuration supplémentaire.

  1. Définissez un rôle d’application dans le manifeste de l’inscription d’application qui représente l’application App Service ou de fonction que vous souhaitez protéger.

  2. Dans l’inscription d’application qui représente le client à autoriser, sélectionnez Autorisations de l’API>Ajouter une autorisation>Mes API.

  3. Sélectionnez l’inscription d’application que vous avez créée précédemment. Si vous ne voyez pas l’inscription d’application, vérifiez que vous avez ajouté un rôle d’application.

  4. Sous Autorisations de l’application, sélectionnez le rôle d’application que vous avez créé précédemment. Sélectionnez ensuite Ajouter des autorisations.

  5. Veillez à sélectionner Accorder un consentement administrateur pour autoriser l’application cliente à demander l’autorisation.

    Comme pour le scénario précédent (avant l’ajout de rôles), vous pouvez maintenant demander un jeton d’accès pour la même resource cible, et le jeton d’accès inclut une revendication roles contenant les rôles d’application qui ont été autorisés pour l’application cliente.

Dans le code de l’application App Service ou de fonction cible, vous pouvez maintenant vérifier que les rôles attendus sont présents dans le jeton. L’authentification App Service n’effectue pas cette vérification. Pour plus d’informations, consultez la section Revendications d’utilisateurs d’accès.

Vous avez configuré une application cliente démon qui peut accéder à votre application App Service en utilisant sa propre identité.

Bonnes pratiques

Quelle que soit la configuration que vous utilisez pour configurer l’authentification, les bonnes pratiques suivantes garantissent la sécurisation de votre locataire et de vos applications :

  • Configurez chaque application App Service avec sa propre inscription d'application dans Microsoft Entra.
  • Donnez à chaque application App Service ses propres autorisations et son propre consentement.
  • Évitez le partage d’autorisations entre les environnements. Utilisez des inscriptions d’applications distinctes pour les différents emplacements de déploiement. Dans le cadre des tests d’un nouveau code, cette pratique peut permettre d’éviter que des problèmes n’affectent l’application de production.

Migrer vers Microsoft Graph

Il est possible que certaines applications plus anciennes soient configurées avec une dépendance vis-à-vis d’Azure AD Graph, qui est déconseillé et voué à être complètement mis hors service. Par exemple, votre code d’application peut appeler Azure AD Graph pour vérifier l’appartenance de groupe dans le cadre d’un filtre d’autorisation de pipeline d’intergiciels (middlewares). Les applications doivent passer à Microsoft Graph. Si vous souhaitez en savoir plus, veuillez consulter Migrer vos applications d’Azure AD Graph vers Microsoft Graph.

Au cours de cette migration, vous serez peut-être amené à apporter quelques modifications à votre configuration de l’authentification App Service. Une fois que vous aurez ajouté les autorisations Microsoft Graph à l’inscription de votre application, vous pourrez :

  1. Mettre à jour l’URL de l’émetteur de sorte qu’elle comporte le suffixe /v2.0, si ce n’est pas déjà le cas.

  2. Supprimez les demandes d’autorisation Azure AD Graph de votre configuration de connexion. Les propriétés à modifier dépendent de la version de l’API de gestion que vous utilisez :

    • Si vous utilisez l’API V1 (/authsettings), ce paramètre se trouve dans le tableau additionalLoginParams.
    • Si vous utilisez l’API V2 (/authsettingsV2), ce paramètre se trouve dans le tableau loginParameters.

    Vous devez supprimer toute référence à https://graph.windows.net, par exemple. Cette modification inclut le paramètre resource, qui n’est pas pris en charge par le point de terminaison /v2.0, ou les éventuelles étendues que vous demandez spécifiquement et qui proviennent d’Azure AD Graph.

    Vous devez également mettre à jour la configuration pour demander les nouvelles autorisations Microsoft Graph que vous avez configurées pour l’inscription d’application. Vous pouvez utiliser l’étendue .default pour simplifier cette configuration dans un grand nombre de cas. Pour ce faire, ajoutez un nouveau paramètre de connexion scope=openid profile email https://graph.microsoft.com/.default.

Avec ces modifications, lorsque l’authentification App Service tente de se connecter, elle ne demande plus d’autorisations à Azure AD Graph. Au lieu de cela, elle obtient un jeton pour Microsoft Graph. Toute utilisation de ce jeton dans le code de votre application doit également être mise à jour, comme décrit dans Migrer vos applications d’Azure AD Graph vers Microsoft Graph.

Étapes suivantes