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

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.

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.

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": []
            }
        }
    }
}

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

• Présentation de l’authentification/autorisation App Service.
• Tutoriel : Authentifier et autoriser des utilisateurs de bout en bout dans Azure App Service

• Tutoriel : Authentifier et autoriser des utilisateurs dans une application Web qui accède à Azure Storage et à Microsoft Graph
• Tutoriel : Authentifier et autoriser des utilisateurs de bout en bout dans Azure App Service