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

  • Article

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 ID) comme fournisseur d’authentification pour la connexion des utilisateurs.

La fonctionnalité d’authentification App Service peut créer automatiquement une inscription d’application avec la plateforme d’identités Microsoft. Vous pouvez également utiliser une inscription créée séparément par vous-même ou par un administrateur de répertoire.

Remarque

L’option permettant de créer automatiquement une inscription n’est pas disponible pour les clouds gouvernementaux ou lors de l’utilisation de [Microsoft Entra ID pour les clients (préversion)]. Au lieu de cela, définissez une inscription 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. Vous pouvez personnaliser l’inscription de l’application dans Microsoft Entra ID une fois qu’elle a été créée.

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

  2. Sélectionnez Authentification dans le menu de gauche. Sélectionnez Ajouter un fournisseur d’identité.

  3. Sélectionnez Microsoft dans la liste déroulante de fournisseurs d’identité. L’option permettant de créer une nouvelle inscription est sélectionnée par défaut. Vous pouvez modifier le nom de l’inscription ou les types de comptes pris en charge.

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

  4. S’il s’agit du premier fournisseur d’identité configuré pour l’application, une section des paramètres d’authentification App Service s’affichera. Sinon, vous pouvez passer à l’étape suivante.

    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.

  5. (Facultatif), 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.

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

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

Vous pouvez configurer l’authentification App Service pour utiliser une inscription d’application existante. 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.

Étape 1 : création d’une inscription d’application dans Microsoft Entra ID pour votre application App Service

Pendant l’étape de l’inscription d’application, recueillez les informations suivantes, car vous en aurez besoin plus tard pour configurer l’authentification dans l’application App Service :

  • ID client
  • ID client
  • Clé secrète client (facultative, mais recommandée)
  • URI d’ID d’application

Les instructions de création d’une inscription d’application dépendent de si vous utilisez un locataire personnel ou un locataire client. Utilisez les onglets ci-dessous pour sélectionner l’ensemble d’instructions approprié pour votre scénario.

Pour inscrire l’application, effectuez les étapes suivantes :

  1. Connectez-vous au Azure portal, recherchez et sélectionnez App Services, puis sélectionnez votre application. Notez l’URL de votre application. Vous allez l’utiliser pour configurer l’inscription de votre application Microsoft Entra.

  2. Accédez à votre locataire dans le portail :

    Dans le menu du portail, sélectionnez Microsoft Entra ID. Si le locataire que vous utilisez est différent de celui que vous utilisez pour configurer l’application App Service, vous devez d’abord modifier les répertoires.

  3. Dans l’écran « Vue d’ensemble », notez l’ID de locataire, ainsi que le domaine principal.

  4. Dans le volet de navigation de gauche, sélectionnez Inscriptions d'applications>Nouvelle inscription.

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

  6. Dans Types de comptes pris en charge, sélectionnez le type de compte qui peut accéder à cette application.

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

  8. Sélectionnez Inscription.

  9. Une fois l’inscription d’application créée, copiez l’ID de l’application (client) et l’ID de l’annuaire (locataire) pour plus tard.

  10. À partir du volet de navigation gauche, sélectionnez Authentication. Sous Octroi implicite et flux hybrides, activez Jetons d’ID pour autoriser les connexions utilisateur OpenID Connect à partir d’App Service. Sélectionnez Enregistrer.

  11. (Facultatif) Dans le volet de navigation de gauche, sélectionnez Propriétés de personnalisation. Dans URL de la page d’accueil, entrez l’URL de votre application App Service, puis sélectionnez Enregistrer.

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

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

  14. (Facultatif) 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.

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

  16. Terminez la configuration de l’inscription de votre application :

    Aucune autre étape n’est nécessaire pour un locataire personnel.

Étape 2 : activation de Microsoft Entra ID dans votre application App Service

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

  2. Dans le volet de navigation de gauche, sélectionnez Authentification>Ajouter le fournisseur d’identité>Microsoft.

  3. Sélectionnez le type de locataire de l’inscription d’application que vous avez créée.

  4. Configurez l’application pour utiliser l’inscription que vous avez créée, en suivant les instructions pour le type de locataire approprié :

    Pour le type d’inscription de l’application, choisissez l’une des options suivantes :

    • Choisissez une inscription d’application existante dans ce répertoire : sélectionnez une inscription d’application à partir du locataire actuel et regroupez automatiquement les informations nécessaires concernant l’application. Le système tente de créer une clé secrète client sur l’inscription de l’application et de configurer automatiquement votre application pour l’utiliser. Une URL d’émetteur par défaut est définie en fonction des types de comptes pris en charge configurés dans l’inscription de l’application. Si vous envisagez de modifier cette valeur par défaut, consultez le tableau suivant.
    • Fournissez les détails d’une inscription d’application existante : spécifiez les détails d’une inscription d’application à partir d’un autre locataire ou si votre compte n’est pas autorisé dans le locataire actuel à interroger les inscriptions. Pour cette option, vous devez remplir manuellement les valeurs de configuration en fonction du tableau suivant.

    Le point de terminaison d’authentification d’un locataire de main-d’œuvre doit être une valeur spécifique à l’environnement cloud. Par exemple, un locataire de main-d’œuvre dans Azure global utiliserait «https://login.microsoftonline.com" comme point de terminaison d’authentification. Notez la valeur du point de terminaison d’authentification, car elle est nécessaire pour construire l’URL de l’émetteur appropriée.

    Lorsque vous renseignez directement les détails de la configuration, utilisez les valeurs que vous avez collectées pendant le processus de création de l’inscription de l’application :

    Champ Description
    ID d’application (client) Utilisez l'ID d’application (client) de l’inscription de l’application.
    Clé secrète client Utilisez la clé secrète client que vous avez générée lors de l’inscription de l’application. Avec une clé secrète client, le flux hybride est utilisé et App Service retourne les jetons d’accès et d’actualisation. Lorsque la clé secrète client n’est pas définie, le flux implicite est utilisé et seul un jeton d’ID est retourné. Ces jetons sont envoyés par le fournisseur et stockés dans le magasin de jetons App Service.
    URL de l’émetteur Utilisez <authentication-endpoint>/<tenant-id>/v2.0, puis remplacez <authentication-endpoint> par le point de terminaison d’authentification que vous avez déterminé à l’étape suivante pour votre type de locataire et d’environnement cloud, puis <tenant-id>> par l’ID du répertoire (locataire) dans lequel l’inscription de l’application a été créée. Pour les applications qui utilisent Azure AD v1, omettez /v2.0 dans l’URL.

    Cette valeur sert à rediriger les utilisateurs vers le bon locataire Microsoft Entra, mais aussi à télécharger les métadonnées appropriées pour déterminer les clés de signature de jetons et la valeur de revendication de l’émetteur de jeton qui conviennent, par exemple. Toute configuration autre qu’un point de terminaison spécifique au locataire sera traitée comme multilocataire. Dans les configurations multilocataires, aucune validation de l’émetteur ou de l’ID de locataire n’est effectuée par le système, et ces vérifications doivent être entièrement gérées dans la logique d’autorisation de votre application.
    Audiences de jeton autorisées Ce champ est facultatif. L’ID d’application client configuré est toujours implicitement considéré comme une audience autorisée. Si votre application représente une API qui sera appelée par d’autres clients, vous devez également ajouter l’URI d’ID d’application que vous avez configuré lors de l’inscription de l’application. Il existe une limite de 500 caractères dans la liste des audiences autorisées.

    La clé secrète client est stocké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.

  5. S’il s’agit du premier fournisseur d’identité configuré pour l’application, une section des paramètres d’authentification App Service s’affichera. Sinon, vous pouvez passer à l’étape suivante.

    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.

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

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 tirer parti des 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 contenant jusqu’à 10 ID de tenant (par exemple, « 559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc ») pour exiger que le jeton entrant provienne de l’un des tenants spécifiés, tel que 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 ID 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 ID.

  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 celle-ci n’apparaît pas, vérifiez que vous avez ajouté l’étendue user_impersonation dans Créer une inscription d’application dans Microsoft Entra ID pour votre application App Service.

  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 ID.
  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é.

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

Étapes suivantes