Configurer l’authentification et l’autorisation pour les applications de fonction
Une application de fonctions exposée en tant que point de terminaison HTTP sans authentification est directement accessible par tout client qui découvre l’URL. Azure Functions n'applique pas l'authentification par défaut : la plateforme approuve l'application pour l'implémenter. Pour les fonctions de traitement des commandes de Contoso Retail, qui reçoivent des appels entrants à partir de systèmes partenaires externes, ce point de départ par défaut est incorrect.
Comprendre l’authentification Azure App Service
L’authentification d’Azure App Service — communément appelée EasyAuth — est un intergiciel d’authentification intégré qui s’exécute en tant que composant distinct sur la même plateforme que votre application de fonction. Lorsqu’elle est activée, chaque requête HTTP entrante passe par la couche d’authentification avant l’exécution de votre code de fonction. EasyAuth valide les jetons, gère les sessions authentifiées et injecte des informations d’identité dans les en-têtes de requête. Vous n’avez pas besoin d’ajouter des bibliothèques d’authentification à votre code de fonction ou de modifier une logique de fonction.
EasyAuth prend en charge plusieurs fournisseurs d’identité : Microsoft Entra ID, Facebook, Google, X, GitHub et tout fournisseur compatible OpenID Connect. Pour les charges de travail d’entreprise, Microsoft Entra ID est le bon choix. Lorsque vous configurez Microsoft Entra en tant que fournisseur, EasyAuth valide le jeton du porteur sur chaque requête auprès de votre locataire, toute demande sans jeton valide est arrêtée au niveau de la couche middleware.
Note
L’activation de EasyAuth redirige automatiquement toutes les requêtes entrantes vers HTTPS, quels que soient les paramètres d’application HTTPS existants de votre application de fonction. Les jetons d’authentification ne sont jamais transmis via des connexions HTTP non chiffrées.
Configurer Microsoft Entra ID en tant que fournisseur d’identité
Pour configurer l'authentification Microsoft Entra ID, accédez à Authentication dans l'écran des paramètres de l'application de fonction et ajoutez Microsoft Entra ID en tant que fournisseur d'identité. Azure prend en charge deux modes de configuration :
- Configuration express : Azure crée automatiquement une nouvelle inscription d’application dans le locataire Microsoft Entra associé à votre abonnement. Il s’agit du chemin le plus rapide pour les déploiements greenfield où aucune inscription existante n’est requise. L’inscription est limitée à votre application de fonction et est configurée automatiquement avec les URI de redirection appropriés.
- Configuration avancée : vous indiquez un enregistrement d’application existant : l’ID d’application (client) et l’URL de l’émetteur (le point de terminaison de votre locataire Microsoft Entra). Utilisez ce mode lorsque l’inscription de l’application est gérée de manière centralisée par votre équipe d’identité, lorsque vous devez configurer des revendications ou des autorisations d’API spécifiques, ou lorsque la fonction doit apparaître en tant qu’application d’entreprise connue dans votre annuaire.
Une fois le fournisseur d’identité configuré, EasyAuth applique l’authentification en fonction de l’action à entreprendre lorsque la demande n’est pas authentifiée :
- Require authentication : toute demande sans jeton de porteur de Microsoft Entra valide est rejetée avec une réponse 401 ou redirigée vers la page de connexion du fournisseur d’identité. Le code de fonction n’est jamais exécuté pour les requêtes non authentifiées. Il s’agit du paramètre correct pour les applications de fonction qui doivent accepter uniquement les appels des appelants authentifiés.
- Autoriser les demandes non authentifiées : les demandes passent à la fonction indépendamment de l’état d’authentification. EasyAuth valide toujours les jetons lorsqu’ils sont présents et injecte des en-têtes d’identité, mais il ne bloque pas les appelants non authentifiés. Utilisez ce mode lorsque la fonction elle-même gère les décisions d’authentification, par exemple lorsqu’elle doit répondre différemment aux demandes anonymes et authentifiées.
Pour les déclencheurs HTTP entrants de Contoso Retail, qui doivent accepter uniquement les appels des systèmes partenaires contenant un jeton de Microsoft Entra valide, Require authentication est le paramètre correct. Aucune modification du code de fonction n’est requise.
Important
Par défaut, tout utilisateur de votre locataire Microsoft Entra peut obtenir un jeton pour votre application et appeler des fonctions authentifiées. Si vous devez restreindre l’accès à un groupe, une application ou un ensemble d’utilisateurs spécifique, configurez l’inscription de l’application dans Microsoft Entra pour exiger l’affectation, puis attribuez uniquement les identités que vous souhaitez autoriser.
Comprendre les niveaux d’autorisation de fonction
Outre EasyAuth, Azure Functions inclut son propre mécanisme d’autorisation léger : niveaux d’autorisation de fonction. Ce mécanisme utilise des clés API pour gérer l’accès aux points de terminaison de fonction et fonctionne indépendamment de EasyAuth.
Les niveaux d’autorisation sont définis par fonction ou au niveau de l’application de fonction :
- Anonyme : aucune clé API n’est requise. Tout appelant peut appeler la fonction sans clé. Utilisez ce niveau uniquement lorsque EasyAuth ou une passerelle en amont protège le point de terminaison. Une fonction anonyme sans couche d’authentification en amont n’est pas un point de terminaison HTTP entièrement ouvert.
- Fonction : nécessite une clé spécifique à cette fonction individuelle. Chaque fonction de l’application peut avoir son propre ensemble de clés. Un appelant avec la clé d’une fonction ne peut pas appeler d’autres fonctions dans la même application.
- Hôte : nécessite la clé hôte, qui est partagée entre toutes les fonctions de l’application de fonction. Un appelant avec la clé hôte peut appeler n’importe quelle fonction dans l’application. La clé hôte est également appelée clé d’administration lorsqu’elle est utilisée pour les opérations d’administration.
Les clés de fonction ne sont pas un substitut à l’authentification basée sur l’identité. Les clés API sont des chaînes statiques qui peuvent être extraites du code ou de la configuration et partagées par inadvertance. Pour les applications de fonction de production où EasyAuth est configuré avec Microsoft Entra ID, les niveaux d’autorisation de fonction fournissent une défense en profondeur, une couche secondaire qui exige que l’appelant présente à la fois une clé valide et un jeton d’identité valide.
Important
N'utilisez pas le niveau d'autorisation anonyme sans couche d'authentification en amont, par exemple EasyAuth ou Gestion des API Azure. Une fonction anonyme sans protection est un point de terminaison HTTP entièrement ouvert sur l’Internet public.
Attribuer une identité managée pour les connexions sortantes
Le deuxième écart de Contoso Retail : les chaînes de connexion Cosmos DB stockées en tant que paramètres d’application en texte brut constituent un problème de gestion des informations d’identification. Les paramètres d’application d’une application de fonction sont visibles par toute personne disposant d’un accès en lecture à l’écran de configuration d’App Service. Une chaîne de connexion en texte brut dans un paramètre d’application constitue un chemin direct entre l’accès à la configuration de l’application de fonction et l’accès complet à la base de données en aval.
Les identités managées résolvent ce problème en donnant à l’application de fonction une identité Microsoft Entra ID qui Azure gère automatiquement. L’application Function s’authentifie auprès des services Azure cibles à l’aide de cette identité — aucune chaîne de connexion requise, aucune information d’identification à stocker, renouveler ou exposer accidentellement.
Pour activer une identité managée affectée par le système, accédez à Identity dans les paramètres de l’application de fonction et définissez Status sur Activé. Azure crée un principal de service pour l’application Azure Functions dans le tenant Microsoft Entra. Vous attribuez ensuite à ce principal de service le rôle approprié sur chaque ressource en aval :
| Service en aval | Rôle recommandé |
|---|---|
| Azure Cosmos DB, une base de données distribuée globale | Contributeur de données intégré Cosmos DB |
| Azure Service Bus (Bus de service Azure) | Émetteur de données Service Bus ou Récepteur de données Service Bus |
| stockage Azure | Contributeur aux données blob du stockage ou Contributeur aux données des files d’attente du stockage |
| Azure Key Vault | Utilisateur des secrets de Key Vault |
| Azure OpenAI | Utilisateur OpenAI de Cognitive Services |
Note
Les applications de fonction jouent de plus en plus le rôle d’orchestrateurs d’agents IA — en coordonnant les appels aux modèles Azure OpenAI, aux points de terminaison Azure AI Foundry ou aux déploiements personnalisés de flux de prompts. Lorsqu’une application de fonction appelle un point de terminaison OpenAI Azure, l’identité managée avec le rôle Cognitive Services OpenAI User est le modèle d’authentification approprié. Cela élimine le stockage de clé API dans les paramètres d’application et garantit que l’accès au point de terminaison de modèle est contrôlé et auditable via Azure RBAC.
Avec l’identité managée activée et les rôles attribués, mettez à jour chaque appel de service en aval dans votre code de fonction pour utiliser DefaultAzureCredential à partir du Kit de développement logiciel (SDK) Azure Identity au lieu d’un chaîne de connexion. Les informations d’identification récupèrent automatiquement l’identité managée de l’application Function au moment de l’exécution. Pour les configurations de déclencheur et de liaison qui font référence à des services Azure — comptes de stockage pour les déclencheurs de file d’attente, Service Bus pour les déclencheurs de rubrique —, la propriété de connexion dans la configuration de la fonction prend également en charge l’identité gérée via des connexions basées sur l’identité, plutôt qu’au moyen de valeurs de chaîne de connexion.