Partager via

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

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

Avant que votre application puisse connecter des utilisateurs, vous devez l'enregistrer dans un locataire de personnel 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 comme valeur du 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 des effectifs (locataire actuel) pour les employés et les invités professionnels
    • Configuration externe pour les consommateurs et les clients professionnels

Choisir l’inscription d’application

La fonctionnalité d’authentification App Service peut créer automatiquement une inscription d’application pour vous. Vous pouvez également utiliser une inscription que vous ou un administrateur d’annuaire 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 l’inscription d'une application provenant d'un autre locataire Microsoft Entra que celui qui héberge votre application. Cela est toujours le cas si vous avez sélectionné la configuration externe lorsque vous avez choisi un locataire.
  • L’option permettant de créer une nouvelle inscription n’est pas disponible pour les clouds gouvernementaux.

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

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

  2. Pour Nom, entrez le nom de la nouvelle inscription d’application.

  3. Sélectionnez la valeur de 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 n’importe quel annuaire organisationnel et comptes Microsoft personnels (par exemple, Skype ou Xbox). Tous les utilisateurs disposant d’un compte professionnel ou scolaire, ou d’un compte Microsoft personnel, peuvent utiliser votre application ou VOTRE API. Il inclut les écoles et les entreprises qui utilisent Office 365, ainsi que des 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. Vous pouvez également modifier cette option pour utiliser une identité au lieu d’une clé secrète client. La prise en charge de l’utilisation d’une identité est actuellement en version d'essai.

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

Pour utiliser une inscription existante, sélectionnez :

  • Choisissez une inscription d’application existante dans ce répertoire. Sélectionnez ensuite une inscription d’application dans la liste déroulante.

  • Fournissez les détails d’une inscription d’application existante. Ensuite, fournissez :

    • ID d’application (client).

    • Clé secrète client (recommandé). Valeur secrète utilisée par l’application pour prouver son identité lorsqu’elle demande 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, que nous vous déconseillons .

      Vous pouvez également configurer l’application pour utiliser une identité au lieu d’une clé secrète client. La prise en charge de l’utilisation d’une identité est actuellement en version d'essai.

    • URL de l’émetteur. Cette URL prend 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 type 'workforce' dans Azure globalement 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.

Pendant le processus d’inscription, dans la section URI de redirection , sélectionnez Web pour la plateforme, puis entrez un URI de redirection. Par exemple, saisissez https://contoso.azurewebsites.net/.auth/login/aad/callback.

À présent, modifiez l’inscription de l’application :

  1. Dans le volet gauche, sélectionnez Exposer une API>Ajouter>Enregistrer. Cette valeur identifie de manière unique l’application lorsqu’elle est utilisée en tant que ressource, ce qui permet aux jetons qui accordent l’accès à être demandé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, en fonction de l’un des domaines vérifiés pour votre locataire. Pour une application mutualisée, vous devez fournir un URI personnalisé. Pour plus d’informations sur les formats acceptés pour les URI d’ID d’application, consultez les meilleures pratiques de sécurité pour les propriétés d’application dans Microsoft Entra ID.

  2. Sélectionnez Ajouter une étendue, puis :

    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 une description que vous souhaitez que les utilisateurs voient sur la page de consentement. Par exemple, entrez Accessapplication-name.
    4. Sélectionnez Ajouter une étendue.

  3. (Recommandé) Créez une assertion cliente pour l’application. Pour créer un secret client :

    1. Dans le volet gauche, sélectionnez Certificats et secrets>Secrets client>Nouveau secret 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 vous éloignez de cette page, elle n’apparaît plus.

    Vous pouvez également configurer l’application pour utiliser une identité au lieu d’une clé secrète client. La prise en charge de l’utilisation d’une identité est actuellement en version d'essai.

  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 vous pouvez ajuster ces paramètres ultérieurement à partir de la page d’authentification principale en sélectionnant Modifier en regard des paramètres d’authentification.

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

  • Autorisez uniquement les requêtes de cette application elle-même.
  • Autoriser les demandes provenant d’applications clientes spécifiques.
  • Autoriser les demandes de n’importe quelle application (non recommandée).

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

  • Autoriser les requêtes de n’importe quelle identité.
  • Autoriser les demandes provenant d’identités spécifiques.

Pour Exigence de locataire, choisissez s’il faut :

  • Autoriser les requêtes uniquement provenant du locataire émetteur.
  • Autoriser les demandes provenant de locataires spécifiques.
  • Utilisez 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 plus loin dans cet article.

Configurer les paramètres d’authentification

Les paramètres d’authentification 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 personnaliser ce comportement maintenant, ou vous pouvez ajuster ces paramètres ultérieurement à partir de la page d’authentification principale en sélectionnant Modifier en regard des 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 demandes non authentifiées, choisissez les options d’erreur :

  • HTTP 302 Found redirect: recommandé pour les sites web
  • HTTP 401 Unauthorized: recommandé pour les API
  • HTTP 403 Forbidden
  • HTTP 404 Not found

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 ultérieurement si votre application n’a pas besoin de jetons ou si vous devez optimiser les performances.

Ajouter le fournisseur d’identité

Si vous avez sélectionné la configuration de la main-d’œuvre, vous pouvez sélectionner Suivant : Autorisations et ajouter les autorisations Microsoft Graph dont l’application a besoin. 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é dans la page 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 fournit des vérifications intégrées, ce qui peut vous aider, mais elles peuvent ne pas suffire pour couvrir les besoins d’autorisation de votre application. Les sections suivantes couvrent ces fonctionnalités.

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 de quel locataire provient la demande. Une application peut être limitée à des locataires spécifiques, selon que l’organisation s’est inscrite 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 votre code d’application, vous pouvez utiliser les informations de revendication 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, il permet également à toute personne 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 validation section qui peut inclure un defaultAuthorizationPolicy objet, comme indiqué dans la structure suivante :

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Propriété Descriptif
defaultAuthorizationPolicy Groupe de conditions requises qui doivent être remplies pour l’accès à l’application. L’accès est accordé en fonction d’une logique AND sur chacune de ses propriétés configurées. Quand allowedApplications et allowedPrincipals sont tous les deux configurés, la demande entrante doit répondre aux deux exigences à accepter.
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 Groupe de vérifications qui déterminent si le principal que la demande entrante représente 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) Une liste blanche d'ID d'objets de chaîne qui représentent les utilisateurs ou les applications qui ont accès. Lorsque cette propriété est configurée en tant que tableau non vide, l’exigence allowedPrincipals peut être satisfaite si l’utilisateur ou l’application que la demande représente est spécifiée dans la liste. Il existe une limite de 500 caractères (total) dans la liste des identités.

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

En outre, vous pouvez configurer certaines vérifications via un paramètre d’application, quelle que soit la version de l’API que vous utilisez. Vous pouvez configurer le WEBSITE_AUTH_AAD_ALLOWED_TENANTS paramètre d’application 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.

Vous pouvez configurer le WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL paramètre d’application sur true ou 1pour exiger que le jeton entrant inclue une oid revendication. Si vous avez configuré allowedPrincipals.identities, ce paramètre est ignoré et traité comme vrai, car la oid revendication est vérifiée sur cette liste d’identités fournie.

Les requêtes qui échouent dans ces vérifications intégrées obtiennent une réponse HTTP 403 Forbidden .

Utilisez une identité gérée au lieu d'un secret (aperçu)

Au lieu de configurer une clé secrète client pour l'enregistrement de votre application, vous pouvez configurer une application pour faire confiance à une identité managée (version préliminaire). L’utilisation d’une identité au lieu d’un secret signifie que vous n’avez pas besoin de gérer un secret. Vous n’avez pas d’événements d’expiration de secret à gérer, et vous n’avez pas le même niveau de risque associé à la divulgation ou à la fuite de ce secret.

L’identité vous permet de créer des identifiants d'identité fédérée, qui peuvent être utilisés au lieu d’un secret client comme assertion client. Cette approche est disponible uniquement pour les configurations de main-d’œuvre. La fonctionnalité d’authentification intégrée prend actuellement en charge les informations d’identification d’identité fédérées en préversion.

Vous pouvez utiliser les étapes décrites dans cette section pour configurer votre ressource App Service ou Azure Functions pour utiliser ce modèle. Les étapes suivantes supposent que vous avez déjà configuré une inscription d’application à l’aide de l’une des méthodes prises en charge et que vous avez déjà défini un secret.

  1. Créez une ressource d’identité managée attribuée par l’utilisateur en suivant ces instructions.

  2. Attribuez cette identité à votre ressource App Service ou Azure Functions.

    Important

    L'identité managée assignée par l'utilisateur que vous créez doit être uniquement affectée à l'application App Service ou Azure Functions à travers cet enregistrement. Si vous attribuez l’identité à une autre ressource, vous donnez à cette ressource un accès inutile à votre inscription d’application.

  3. Notez l’ID d’objet et les valeurs d’ID client de l’identité managée. Vous aurez besoin de l’ID d’objet pour créer un justificatif d’identité fédéré à l’étape suivante. Vous allez utiliser l’ID client de l’identité managée dans une étape ultérieure.

  4. Suivez les instructions de Microsoft Entra ID pour configurer des informations d’identification d’identité fédérée sur une application existante. Ces instructions incluent également des sections pour mettre à jour le code d’application, que vous pouvez ignorer.

  5. Ajoutez un nouveau paramètre d’application nommé OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Définissez sa valeur sur la valeur d’ID client de l’identité managée que vous avez obtenue à l’étape précédente. N’utilisez pas l’ID client de votre inscription d’application. Assurez-vous de marquer ce paramètre d'application comme étant collant.

  6. Dans les paramètres d’authentification intégrés de votre ressource d’application, définissez le nom du paramètre de secret client sur OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

    Pour apporter cette modification à l’aide du portail Azure :

    1. Revenez à votre ressource App Service ou Azure Functions, puis sélectionnez l’onglet Authentification .
    2. Dans la section Fournisseur d’identité , pour l’entrée Microsoft , sélectionnez l’icône dans la colonne Modifier .
    3. Dans la boîte de dialogue Modifier le fournisseur d’identité, ouvrez la liste déroulante pour le nom du paramètre secret client et sélectionnez .OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID
    4. Cliquez sur Enregistrer.

    Pour apporter cette modification à l’aide de l’API REST :

    • Attribuez à la propriété clientSecretSettingName la valeur OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Vous trouverez cette propriété sous properties>identityProviders>azureActiveDirectory>registration.

  7. Vérifiez que l’application fonctionne comme prévu. Vous devez être en mesure d’effectuer une nouvelle action de connexion.

Lorsque vous êtes satisfait du comportement à l’aide d’une identité managée, supprimez le secret existant :

  1. Assurez-vous que le code de votre application ne dépend pas du paramètre d’application. Si c’est le cas, suivez les instructions pour mettre à jour le code de votre application pour demander un jeton d’accès.

  2. Supprimez le paramètre d’application qui contenait précédemment votre secret. Le nom de ce paramètre d’application est la valeur précédente de nom du paramètre secret client, avant de le définir sur OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

  3. Connectez-vous au centre d’administration Microsoft Entra en utilisant le locataire qui contient l’enregistrement de votre application. Accédez à nouveau à l’inscription de l’application.

  4. Sous Certificats et secrets, sélectionnez Secrets client et supprimez la clé secrète client.

Votre application est maintenant configurée pour utiliser l’authentification Microsoft Entra ID sans secrets.

Configurer des applications clientes pour accéder à App Service

Dans les sections précédentes, vous avez inscrit votre application App Service ou Azure Functions pour authentifier les utilisateurs. Les sections suivantes expliquent comment inscrire des clients natifs ou des applications démon dans Microsoft Entra. Ces clients ou applications peuvent demander l’accès aux API exposées par App Service pour le compte des utilisateurs ou eux-mêmes, comme dans une architecture à plusieurs niveaux. Si vous souhaitez uniquement authentifier les utilisateurs, les étapes décrites dans les sections suivantes ne sont pas requises.

Application cliente native

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

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

  2. Dans le volet gauche, sélectionnez Gérer les>inscriptions d’applications. Sélectionnez Ensuite Nouvelle inscription.

  3. Dans le volet Inscrire une application , pour Nom, entrez un nom pour l’inscription de votre application.

  4. Dans l’URI de redirection, sélectionnez Client public/natif (mobile &desktop) et entrez l’URL de redirection. Par exemple, saisissez 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) .

    Remarque

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

  7. Dans le volet gauche, sélectionnez Gérer les>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'enregistrement de l'application, assurez-vous d'ajouter la portée user_impersonation dans l'enregistrement de l'application.

  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 Azure Functions pour le compte de l’application cliente elle-même, et non pour le compte d’un utilisateur. Ce scénario est utile pour les applications 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 gauche, sélectionnez Gérer les>inscriptions d’applications. Sélectionnez Ensuite Nouvelle inscription.

  3. Dans le volet Inscrire une application , pour Nom, entrez un nom pour l’inscription de votre application.

  4. Pour une application démon, vous n’avez pas besoin d’un URI de redirection. Vous pouvez donc conserver la zone URI de redirection 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 gauche, sélectionnez Gérer les>certificats et les 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 vous éloignez de cette page, elle n’apparaît plus.

Vous pouvez maintenant demander un jeton d’accès à l’aide de l’ID client et de la clé secrète client. Définissez le paramètre resource sur la valeur URI de l’ID d’application de l’application cible. Le jeton d’accès résultant peut ensuite être présenté à l’application cible via l’en-tête d’autorisation OAuth 2.0 standard. L’authentification App Service valide et utilise le jeton pour 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 l’autorisation pour autoriser uniquement 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 Azure Functions 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 de l’application, vérifiez que vous avez ajouté un rôle d’application.

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

  5. Sélectionnez Accorder le consentement de l’administrateur pour autoriser l’application cliente à demander l’autorisation.

    Comme pour le scénario précédent (avant d’ajouter des rôles), vous pouvez désormais demander un jeton d’accès pour la même ressource cible. Le jeton d’accès inclut une roles revendication qui contient les rôles d’application autorisés pour l’application cliente.

Dans le code d’application App Service ou Azure Functions cible, vous pouvez maintenant vérifier que le jeton a les rôles attendus. L’authentification App Service n’effectue pas cette vérification. Si vous souhaitez en savoir plus, veuillez consulter Accéder aux revendications d’utilisateurs dans le code d’application.

Vous avez maintenant configuré une application cliente démon qui peut accéder à votre application App Service à l’aide de sa propre identité.

Bonnes pratiques

Quelle que soit la configuration que vous utilisez pour configurer l’authentification, les meilleures pratiques suivantes permettent à vos clients et applications de sécuriser davantage :

  • 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. Lorsque vous testez du nouveau code, cette pratique peut empêcher les problèmes d’affecter l’application de production.

Migrer vers Microsoft Graph

Certaines applications plus anciennes peuvent être configurées avec une dépendance sur Azure AD Graph, qui est déconseillée et planifiée pour une mise hors service complète. 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 :

  • Mettez à jour la valeur de l’URL de l’émetteur pour inclure le /v2.0 suffixe si ce n’est pas déjà fait.

  • 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 resource paramètre, que le /v2.0 point de terminaison ne prend pas en charge. Il inclut également toutes les étendues que vous demandez spécifiquement à partir 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. Dans de nombreux cas, vous pouvez utiliser l’étendue par défaut pour simplifier cette configuration. 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, il 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.

Contenu connexe