Partager via

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

  • Article

Remarque

Depuis le 1er juin 2024, toutes les applications App Service nouvellement créées ont la possibilité de générer un nom d’hôte par défaut unique en utilisant la convention d’affectation de noms <app-name>-<random-hash>.<region>.azurewebsites.net. Les noms d’application existants restent inchangés.

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

Pour plus d’informations, reportez-vous à Nom d’hôte par défaut unique pour la ressource 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 gauche de votre application, sélectionnez 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. Pour Type de locataire, 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 pour vous, ou 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.

Créer et utiliser une inscription d’application ou Utiliser une inscription créée séparément.

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. Une fois l’inscription d’application créée, vous pouvez la personnaliser dans Microsoft Entra ID.

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.

Entrez le Nom de la nouvelle inscription d’application.

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. Ceci inclut 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. Vous pouvez mettre à jour ce paramètre ultérieurement pour utiliser des références Key Vault si vous souhaitez gérer le secret dans Azure Key Vault.

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

Un des deux éléments suivants :

  • Sélectionnez Choisir une inscription d’application existante dans ce répertoire et sélectionnez une inscription d’application dans la liste déroulante.
  • Sélectionnez Fournir les détails d’une inscription d’application existante et indiquez les éléments suivants :
    • ID 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.

Pour créer manuellement une inscription d’application dans un locataire de main-d’œuvre, suivez la procédure de démarrage rapide Inscrire une application. 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. Il est utilisé comme 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é. Pour en savoir plus sur les formats acceptés pour les URI ID d’application, consultez les informations de référence sur les recommandations relatives aux inscriptions d’applications.

  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. Dans les zones de texte, entrez le nom et la description de l’étendue de consentement que vous voulez que les utilisateurs voient dans 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. Elle ne s’affiche plus lorsque vous quittez cette page.

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

Configurer des vérifications supplémentaires

Configurez des vérifications supplémentaires qui identifient 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 des décisions d’autorisation supplémentaires 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 manière dont votre application répond aux requêtes non authentifiées, et les sélections par défaut redirigent toutes les requêtes de connexion à l’aide de 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 en savoir plus sur ces options, 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. Si votre application n’a pas besoin de jetons ou que vous devez optimiser les performances, vous pourrez le désactiver ultérieurement.

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. Celles-ci 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, consultez ce tutoriel.

Autoriser des requêtes

Par défaut, l’authentification App Service gère uniquement l’authentification en déterminant si l’appelant est celui qu’il prétend être. L’autorisation, qui détermine si cet appelant doit avoir accès à une ressource, est une étape supplémentaire au-delà de l’authentification. Pour en savoir plus sur ces concepts, consultez Principes de base sur l’autorisation de la plateforme d’identités Microsoft.

Votre application peut prendre des décisions d’autorisation relatives au code. L’authentification App Service fournit des vérifications intégrées, qui peuvent vous aider, mais il se peut qu’elles seules ne suffisent pas pour couvrir les besoins d’autorisation de votre application.

Conseil

Les applications multi-locataires doivent valider l’émetteur et l’ID de tenant 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 multi-locataire, elle ne valide pas le tenant d’où provient la requête. Une application peut avoir besoin d’être limitée à des tenants spécifiques en fonction, par exemple, de l’inscription ou non au service par l’organisation. Consultez le Guide sur la multi-location de la Plateforme d’identités Microsoft.

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. 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 également à toute personne au sein du locataire d’accéder à l’application, ce qui convient à de nombreuses applications. Toutefois, 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 consiste à 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 Regroupement des 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 des ID de client d’application de chaîne autorisés représentant la ressource cliente qui appelle 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. Consultez les Informations de référence sur les revendications de la plateforme d’identités Microsoft.
allowedPrincipals Regroupement 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 des ID d’objet de chaîne autorisés 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. Consultez les Informations de référence sur les revendications de la plateforme d’identités Microsoft.

En outre, 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 allant jusqu’à 10 ID de locataire (par exemple, « aaaabbbb-0000-cccc-1111-dddd2222eeee ») pour exiger que le jeton entrant provient de l’un des locataires spécifiés, comme spécifié par la revendication tid. Le paramètre d’application WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL peut être configuré sur « vrai » ou « 1 » pour exiger que le jeton entrant inclue une revendication oid. Ce paramètre est ignoré et traité comme vrai si allowedPrincipals.identities a été configuré (puisque 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 applications clientes ou démon natives dans Microsoft Entra afin qu’elles puissent demander l’accès aux API exposées par votre application App Service pour le compte d’utilisateurs ou pour elles-mêmes, telles qu’une architecture multiniveau. Il n’est pas nécessaire d’effectuer les étapes de cette section si vous souhaitez uniquement authentifier les utilisateurs.

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.

  2. Dans le volet de navigation de gauche, sélectionnez Inscriptions d'applications>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 (mobile et bureau) et entrez 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 menu de gauche, sélectionnez Autorisations des API>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, assurez-vous que vous avez ajouté l’étendue user_impersonation à ladite inscription.

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

Vous avez maintenant 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 non 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.

  1. Dans le menu du portail, sélectionnez Microsoft Entra.
  2. Dans le volet de navigation de gauche, sélectionnez 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 Certificats et secrets>Clés secrètes de 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. Elle ne s’affiche plus lorsque vous quittez cette page.

Vous pouvez maintenant demander un jeton d’accès à l’aide de l’ID client et de la clé secrète client en définissant le paramètre resource sur 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 indiquer à présent que l’appelant (en l’occurrence, une application, pas un utilisateur) est authentifié.

À l’heure actuelle, cela 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 n’autoriser que 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 représentant l’App Service ou l’application de fonction que vous souhaitez protéger.
  2. Sur l’inscription de l’application représentant le client qui doit être autorisé, 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, assurez-vous que vous avez ajouté un rôle d’application.
  4. Sous Autorisations d’application, choisissez le rôle d’application que vous avez créé précédemment, puis sélectionnez Ajouter des autorisations.
  5. Veillez à sélectionner Accorder un consentement administrateur pour autoriser l’application cliente à demander l’autorisation.
  6. 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.
  7. Dans le code de l’App Service ou de l’application de fonction cibles, vous pouvez désormais vérifier que les rôles attendus sont présents dans le jeton (cela n’est pas effectué par l’authentification App Service). Pour plus d’informations, consultez la section Revendications d’utilisateurs d’accès.

Vous avez maintenant 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 de partager des autorisations entre des environnements en utilisant des inscriptions d’application distinctes pour des emplacements de déploiement distincts. 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

Certaines applications anciennes peuvent aussi avoir été configurées avec une dépendance vis-à-vis du déprécié Azure AD Graph, dont la mise hors service complète est planifiée. Par exemple, votre code d’application peut avoir appelé 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 en suivant les indications fournies par Microsoft Entra dans le cadre du processus de dépréciation d’Azure AD Graph. Ces instructions vous conduiront peut-être à apporter des 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 inclue 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 sont celles qui se trouvent dans le tableau additionalLoginParams.
    • Si vous utilisez l’API V2 (/authsettingsV2), ce sont celles qui se trouvent dans le tableau loginParameters.

    Vous devez supprimer toute référence à « https://graph.windows.net" », par exemple. Cela 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 de l’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, quand l’authentification d’App Service tente de se connecter, elle ne demande plus d’autorisations à Azure AD Graph et obtient un jeton pour Microsoft Graph. Toute utilisation de ce jeton dans votre code d’application devra également être mise à jour, conformément aux indications fournies par Microsoft Entra.

Étapes suivantes