Authentification et autorisation dans Azure App Service et Azure Functions

2025-06-10

Azure App Service fournit des fonctionnalités d’authentification intégrée (connexion d’utilisateurs) et d’autorisation (accès aux données sécurisées). Ces fonctionnalités sont parfois appelées Authentification facile. Vous pouvez les utiliser pour connecter des utilisateurs et accéder aux données en écrivant peu ou pas de code dans votre application web, l’API RESTful, le serveur mobile et les fonctions.

Cet article explique comment App Service contribue à simplifier l’authentification et l’autorisation de votre application.

Raisons d’utiliser l’authentification intégrée

Pour implémenter l’authentification et l’autorisation, vous pouvez utiliser les fonctionnalités de sécurité groupées dans votre framework web de votre choix, ou écrire vos propres outils. L’implémentation d’une solution sécurisée pour l’authentification et l’autorisation peut prendre beaucoup d’efforts. Vous devez suivre les meilleures pratiques et normes du secteur. Vous devez également vous assurer que votre solution reste à jour avec les dernières mises à jour de sécurité, de protocole et de navigateur.

Les fonctionnalités intégrées d’App Service et d’Azure Functions peuvent vous faire gagner du temps et des efforts en fournissant une authentification prête à l’emploi avec des fournisseurs d’identité fédérés. Vous pouvez donc vous concentrer sur le reste de votre application.

Avec App Service, vous pouvez intégrer des fonctionnalités d’authentification dans votre application web ou votre API sans les implémenter vous-même. Cette fonctionnalité est intégrée directement à la plateforme et ne nécessite aucun langage, kit sdk, expertise en sécurité ou code particulier. Vous pouvez l’intégrer à plusieurs fournisseurs de connexion, tels que Microsoft Entra, Facebook, Google et X.

Votre application peut avoir besoin de prendre en charge des scénarios plus complexes, tels que l’intégration de Visual Studio ou le consentement incrémentiel. Plusieurs solutions d’authentification sont disponibles pour prendre en charge ces scénarios. Pour en savoir plus, consultez les scénarios et recommandations d’authentification.

Fournisseurs d’identité

App Service utilise l’identité fédérée. Un fournisseur d’identité Microsoft ou non-Microsoft gère les identités utilisateur et le flux d’authentification pour vous. Les fournisseurs d’identité suivants sont disponibles par défaut :

Fournisseur	Point de terminaison de connexion	Guides pratiques
Microsoft Entra	`/.auth/login/aad`	Connexion à la plateforme App Service Microsoft Entra
Facebook	`/.auth/login/facebook`	Connexion à App Service Facebook
Google	`/.auth/login/google`	Connexion à App Service Google
X	`/.auth/login/x`	Connexion à l'App Service X
Lien avec GitHub	`/.auth/login/github`	Connexion à App Service GitHub
Pomme	`/.auth/login/apple`	Connexion à App Service via Apple (aperçu)
Tout fournisseur OpenID Connect	`/.auth/login/<providerName>`	Connexion à App Service OpenID Connect

Lorsque vous configurez cette fonctionnalité avec un de ces fournisseurs, son point de terminaison de connexion est accessible à des fins d’authentification de l’utilisateur et de validation des jetons d’authentification provenant du fournisseur. Vous pouvez proposer à vos utilisateurs toutes les options de connexion que vous souhaitez parmi celles-ci.

Considérations relatives à l’utilisation de l’authentification intégrée

L’activation de l’authentification intégrée entraîne la redirection automatique de toutes les demandes adressées à votre application vers HTTPS, quel que soit le paramètre de configuration App Service pour appliquer HTTPS. Vous pouvez désactiver cette redirection automatique à l’aide du requireHttps paramètre dans la configuration V2. Toutefois, nous vous recommandons de continuer à utiliser HTTPS et de vous assurer qu’aucun jeton de sécurité n’est jamais transmis via des connexions HTTP non sécurisées.

Vous pouvez utiliser App Service pour l’authentification avec ou sans restreindre l’accès à votre contenu et API de site. Définissez les restrictions d’accès dans la section Paramètres>Authentification> des paramètres de votre application web :

Pour restreindre l’accès aux applications uniquement aux utilisateurs authentifiés, définissez l’action à entreprendre lorsque la demande n’est pas authentifiée pour se connecter avec l’un des fournisseurs d’identité configurés.
Pour authentifier mais ne pas restreindre l’accès, définissez l’action à entreprendre lorsque la demande n’est pas authentifiée pour autoriser les demandes anonymes (aucune action).

Important

Vous devez donner à chaque application ses propres autorisation et consentement. Évitez de partager des autorisations entre des environnements en utilisant des inscriptions d’application distinctes pour des emplacements de déploiement distincts. Lorsque vous testez du nouveau code, cette pratique peut empêcher les problèmes d’affecter l’application de production.

Fonctionnement

Architecture des fonctionnalités

Le composant middleware d’authentification et d’autorisation est une fonctionnalité de la plateforme qui s’exécute sur la même machine virtuelle que votre application. Lorsque vous l’activez, chaque requête HTTP entrante passe par ce composant avant que votre application ne la gère.

L’intergiciel (middleware) de la plateforme gère plusieurs éléments pour votre application :

Authentifie les utilisateurs et les clients avec les fournisseurs d’identité spécifiés
Valide, stocke et actualise les jetons OAuth émis par les fournisseurs d’identité configurés
gestion de la session authentifiée ;
Injecte des informations d’identité dans les en-têtes de demande HTTP

Le module s’exécute séparément de votre code d’application. Vous pouvez le configurer à l’aide des paramètres Azure Resource Manager ou à l’aide d’un fichier de configuration. Aucun Kit de développement logiciel (SDK), aucun langage de programmation spécifique ni aucune modification de votre code d’application ne sont nécessaires.

Architecture des fonctionnalités sur Windows (déploiement sans conteneur)

Le module d’authentification et d’autorisation s’exécute comme un module IIS natif, dans le même bac à sable que votre application. Lorsque vous l’activez, chaque requête HTTP entrante l’transmet avant que votre application ne la gère.

Architecture des fonctionnalités sur Linux avec conteneurs

Le module d’authentification et d’autorisation s’exécute dans un conteneur distinct isolé de votre code d’application. Le module utilise le modèle Ambassadeur pour interagir avec le trafic entrant pour effectuer des fonctionnalités similaires à celles de Windows. Étant donné qu’il ne s’exécute pas en processus, aucune intégration directe avec des frameworks de langage spécifiques n’est possible. Toutefois, les informations pertinentes dont votre application a besoin sont transmises dans les en-têtes de requête.

Flux d’authentification

Le flux d’authentification est le même pour tous les fournisseurs. Elle diffère selon que vous souhaitez vous connecter avec le Kit de développement logiciel (SDK) du fournisseur :

Sans SDK fournisseur : l’application délègue la connexion fédérée à App Service. Cette délégation est généralement le cas avec les applications de navigateur, qui peuvent présenter la page de connexion du fournisseur à l’utilisateur. Le code du serveur gère le processus de connexion. Il est donc également appelé flux dirigé par le serveur ou flux de serveur.

Ce cas s’applique aux applications de navigateur et aux applications mobiles qui utilisent un navigateur incorporé pour l’authentification.
Avec le Kit de développement logiciel (SDK) fournisseur : l’application connecte les utilisateurs au fournisseur manuellement. Ensuite, il envoie le jeton d’authentification à App Service pour validation. Ce processus est généralement le cas avec les applications sans navigateur, qui ne peuvent pas présenter la page de connexion du fournisseur à l’utilisateur. Le code de l’application gère le processus de connexion. Il s’agit donc également d’un flux dirigé par le client ou d’un flux client.

Ce cas s’applique aux API REST, aux clients de navigateur Azure Functions et JavaScript, en plus des applications de navigateur qui ont besoin d’une plus grande flexibilité dans le processus de connexion. Il s’applique également aux applications mobiles natives qui connectent les utilisateurs à l’aide du Kit de développement logiciel (SDK) du fournisseur.

Les appels d’une application de navigateur approuvée dans App Service vers une autre API REST dans App Service ou Azure Functions peuvent être authentifiés via le flux dirigé par le serveur. Pour plus d’informations, consultez Personnaliser la connexion et la déconnexion dans l’authentification Azure App Service.

Le tableau suivant montre les étapes du flux d’authentification.

Étape	Sans le Kit SDK du fournisseur	Avec le Kit SDK du fournisseur
1. Connectez-vous à l’utilisateur	Le fournisseur redirige le client vers `/.auth/login/<provider>`.	Le code client connecte l’utilisateur directement avec le Kit de développement logiciel (SDK) du fournisseur et reçoit un jeton d’authentification. Pour plus d’informations, consultez la documentation du fournisseur.
2. Effectuer une post-authentification	Le fournisseur redirige le client vers `/.auth/login/<provider>/callback`.	Le code client envoie le jeton du fournisseur à `/.auth/login/<provider>` pour la validation.
3. Établir une session authentifiée	App Service ajoute un cookie authentifié à la réponse.	App Service retourne son propre jeton d’authentification au code client.
4. Traitement du contenu authentifié	Le client inclut un cookie d’authentification dans les requêtes suivantes (gérés automatiquement par le navigateur).	Le code client présente le jeton d’authentification dans l’en-tête `X-ZUMO-AUTH` .

Dans le cas des navigateurs clients, App Service peut diriger automatiquement tous les utilisateurs non authentifiés vers /.auth/login/<provider>. Vous pouvez également présenter aux utilisateurs un ou plusieurs /.auth/login/<provider> liens pour vous connecter à votre application à l’aide de leur fournisseur de choix.

Comportement d’autorisation

Dans le portail Azure, vous pouvez configurer App Service avec différents comportements lorsqu’une demande entrante n’est pas authentifiée. Les sections suivantes décrivent les options.

Important

Par défaut, cette fonctionnalité fournit uniquement l’authentification, et non l’autorisation. Votre application peut toujours avoir besoin de prendre des décisions d’autorisation, en plus des vérifications que vous configurez ici.

Accès restreint

Autoriser les demandes non authentifiées : cette option reporte l’autorisation du trafic non authentifié vers votre code d’application. Dans le cas des demandes authentifiées, App Service transmet également les informations d’authentification dans les en-têtes HTTP.

Cette option assure un traitement plus souple des requêtes anonymes. Par exemple, il permet de présenter plusieurs fournisseurs de connexion aux utilisateurs. Vous devez cependant écrire du code.
Exiger l’authentification : cette option rejette tout trafic non authentifié vers votre application. Une action spécifique à entreprendre est spécifiée dans la section Demandes non authentifiées plus loin dans cet article.

Cette option évite d’avoir à écrire du code d’authentification dans l’application. Vous pouvez gérer une autorisation plus fine, telle que l’autorisation spécifique au rôle, en inspectant les revendications de l’utilisateur.

Attention

Cette manière de restreindre l’accès s’applique à tous les appels à votre application qui peuvent ne pas être souhaitables pour les applications souhaitant une page d’accès publique disponible, comme dans de nombreuses applications à page unique. Si des exceptions sont nécessaires, vous devez configurer des chemins exclus dans un fichier de configuration.

Remarque

Lorsque vous utilisez le fournisseur d’identité Microsoft pour les utilisateurs de votre organisation, le comportement par défaut consiste en la possibilité de demander un jeton pour votre application par tout utilisateur de votre locataire Microsoft Entra. Vous pouvez configurer l’application dans Microsoft Entra si vous souhaitez restreindre l’accès à votre application à un ensemble défini d’utilisateurs. App Service propose aussi des vérifications d’autorisation intégrées de base qui peuvent aider à effectuer certaines validations. Pour en savoir plus sur l’autorisation dans Microsoft Entra, consultez concepts de base de l’autorisation Microsoft Entra.

Lorsque vous utilisez le fournisseur d’identité Microsoft pour les utilisateurs de votre organisation, le comportement par défaut est que n’importe quel utilisateur de votre locataire Microsoft Entra peut demander un jeton pour votre application. Vous pouvez configurer l’application dans Microsoft Entra si vous souhaitez restreindre l’accès à votre application à un ensemble défini d’utilisateurs. App Service propose également des vérifications d’autorisation intégrées de base qui peuvent vous aider à effectuer certaines validations. Pour en savoir plus sur l’autorisation dans Microsoft Entra, consultez concepts de base de l’autorisation Microsoft Entra.

Demandes non authentifiées

Redirection HTTP 302 trouvée : recommandé pour les sites web : redirige l’action vers l’un des fournisseurs d’identité configurés. Dans ces cas, un client de navigateur est redirigé vers /.auth/login/<provider> le fournisseur que vous choisissez.
HTTP 401 Non autorisé : recommandé pour les API : retourne une HTTP 401 Unauthorized réponse si la requête anonyme provient d’une application mobile native. Vous pouvez également faire en sorte que le rejet soit HTTP 401 Unauthorized pour toutes les requêtes.
HTTP 403 Interdit : Configurer le rejet de manière à ce qu'il s'applique à HTTP 403 Forbidden toutes les requêtes.
HTTP 404 Introuvable : configure le rejet à HTTP 404 Not found pour toutes les requêtes.

Magasin de jetons

App Service fournit un magasin de jetons intégré. Un magasin de jetons est un référentiel de jetons associés aux utilisateurs de vos applications web, API ou applications mobiles natives. Dès que l’authentification est activée avec un fournisseur, l’application a immédiatement accès à ce magasin de jetons.

Si votre code d’application doit accéder aux données de ces fournisseurs au nom de l’utilisateur, vous devez généralement écrire du code pour collecter, stocker et actualiser ces jetons dans votre application. Les actions peuvent inclure :

Publiez sur la chronologie Facebook de l’utilisateur authentifié.
Lisez les données d’entreprise de l’utilisateur à l’aide de l’API Microsoft Graph.

Avec le magasin de jetons, il suffit de récupérer les jetons en temps utile et de demander à App Service de les actualiser lorsqu’ils ne sont plus valides.

Les jetons d’ID, les jetons d’accès et les jetons d’actualisation sont mis en cache pour la session authentifiée. Seul l’utilisateur associé peut y accéder.

Si vous n’avez pas besoin d’utiliser des jetons dans votre application, vous pouvez désactiver le magasin de jetons sur la paged’authentification> de votre application.

Journalisation et suivi

Si vous activez la journalisation des applications, les traces d’authentification et d’autorisation apparaissent directement dans vos fichiers journaux. Si une erreur d’authentification inattendue se produit, vous trouverez facilement tous les détails dans les journaux des applications existants.

Si vous activez le suivi des demandes ayant échoué, vous pouvez voir exactement quel rôle le module d’authentification et d’autorisation peut jouer dans une demande ayant échoué. Dans les journaux d’activité de suivi, recherchez les références à un module nommé EasyAuthModule_32/64.

Atténuation de la falsification des requêtes intersites

L’authentification App Service atténue la falsification des requêtes intersites en inspectant les requêtes des clients pour vérifier les conditions suivantes :

Il s’agit d’une POST demande authentifiée par le biais d’un cookie de session.
La requête provient d’un navigateur connu, tel que déterminé par l’en-tête HTTP User-Agent .
L'en-tête HTTP Origin ou HTTP Referer est manquant ou n'est pas dans la liste configurée des domaines externes approuvés pour la redirection.
L’en-tête HTTP Origin est manquant ou n’est pas dans la liste configurée d’origines de partage de ressources inter-origines (CORS).

Lorsqu’une requête répond à toutes ces conditions, l’authentification App Service la rejette automatiquement. Vous pouvez contourner cette logique d’atténuation en ajoutant votre domaine externe à la liste de redirection dans Paramètres>Authentification>Modifier les paramètres d’authentification>URL de redirection externes autorisées.

Considérations relatives à l’utilisation d’Azure Front Door

Lorsque vous utilisez Azure App Service avec l’authentification derrière Azure Front Door ou d’autres proxys inverses, tenez compte des actions suivantes.

Désactiver la mise en cache d’Azure Front Door

Désactivez la mise en cache d’Azure Front Door pour le flux de travail d’authentification.

Utiliser le point de terminaison Azure Front Door pour les redirections

App Service n’est généralement pas accessible directement lorsqu’il est exposé par Azure Front Door. Vous pouvez empêcher ce comportement, par exemple, en exposant App Service à l’aide d’Azure Private Link dans Azure Front Door Premium. Pour empêcher que le flux de travail d'authentification ne redirige directement le trafic vers App Service. Pour plus d’informations, consultez l’URI de redirection.

Vérifier qu’App Service utilise l’URI de redirection approprié

Dans certaines configurations, App Service utilise son nom de domaine complet (FQDN) comme URI de redirection, au lieu du nom de domaine complet Azure Front Door. Cette configuration provoque un problème lorsque le client est redirigé vers App Service au lieu d’Azure Front Door. Pour le modifier, définissez forwardProxyStandard pour que App Service respecte l’en-tête X-Forwarded-Host défini par Azure Front Door.

D’autres proxys inverses, tels qu’Azure Application Gateway ou les produits non-Microsoft, peuvent utiliser différents en-têtes et avoir besoin d’un paramètre différent forwardProxy .

Vous ne pouvez pas modifier la forwardProxy configuration à l’aide du portail Azure. Vous devez utiliser az rest.

Paramètres d’exportation

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

Définir les paramètres de mise à jour

Rechercher :

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

Vérifiez que convention est défini sur Standard pour respecter l'en-tête X-Forwarded-Host qu'Azure Front Door utilise.

Paramètres d’importation

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Pour plus d’informations sur l’authentification App Service, consultez :

Pour obtenir des exemples, consultez :

Démarrage rapide : Ajouter l’authentification d’application à votre application web s’exécutant sur Azure App Service
Tutoriel : Authentifier et autoriser les utilisateurs de bout en bout dans Azure App Service
Intégration de .NET Core à Azure AppService Easy Auth (contenu non Microsoft GitHub)
Faire fonctionner l'authentification Azure App Service avec .NET Core (contenu non Microsoft GitHub)

Partager via