Authentification et autorisation dans Azure App Service et Azure Functions

Azure App Service offre des capacités intégrées d’authentification et d’autorisation (parfois appelées « Authentification simple »), ce qui vous permet de connecter les utilisateurs et d’accéder aux données sans avoir à écrire beaucoup de code dans votre application web, votre API RESTful et votre back-end mobile, ainsi que dans Azure Functions. Cet article explique comment App Service contribue à simplifier l’authentification et l’autorisation de votre application.

Pourquoi utiliser l’authentification intégrée ?

Il n’est pas obligatoire d’utiliser cette fonctionnalité pour l’authentification et l’autorisation. Vous pouvez utiliser les fonctionnalités de sécurité groupées dans l’infrastructure web de votre choix, ou vous pouvez écrire vos propres utilitaires. Toutefois, vous devrez vous assurer que votre solution reste à jour avec les dernières mises à jour de sécurité, de protocole et de navigateur.

L’implémentation d’une solution sécurisée pour l’authentification (connexion des utilisateurs) et l’autorisation (accord de l’accès aux données sécurisées) peut nécessiter des efforts considérables. Vous devez veiller à suivre les bonnes pratiques et les normes du secteur, et à tenir à jour votre implémentation. La fonctionnalité d’authentification intégrée pour App Service et Azure Functions peut vous faire gagner du temps et de l’énergie en fournissant une authentification prête à l’emploi avec des fournisseurs d’identité fédérée, ce qui vous permet de vous concentrer sur le reste de votre application.

• Azure App Service vous permet d’intégrer diverses fonctionnalités d’authentification à votre application web ou à votre API sans les implémenter vous-même.
• Il est directement intégré à la plateforme et ne nécessite pas de langage particulier, de kit SDK, d’expertise en matière de sécurité ou même de code spécifique.
• Vous pouvez intégrer à plusieurs fournisseurs de connexion, Par exemple, Microsoft Entra ID, Facebook, Google ou Twitter.

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 différentes sont disponibles pour prendre en charge ces scénarios. Pour en savoir plus, consultez Scénarios d’identité.

Fournisseurs d’identité

App Service utilise l’identité fédérée, dans laquelle un fournisseur d’identité tiers gère automatiquement l’identité des utilisateurs et le flux d’authentification. Les fournisseurs d’identité suivants sont disponibles par défaut :

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 cette fonctionnalité entraînera la redirection automatique des toutes les requêtes adressées à votre application vers HTTPS, quel que soit le paramètre de configuration d’App Service relatif au protocole HTTPS. Vous pouvez désactiver cette option avec le paramètre requireHttps dans la configuration V2. Toutefois, nous vous recommandons d’utiliser le protocole HTTPS et de veiller à ce qu’aucun jeton de sécurité ne soit transmis sur des connexions HTTP non sécurisées.

App Service peut être utilisé pour l’authentification avec ou sans restriction de l’accès au contenu et aux API de votre site. Pour limiter l’accès aux applications uniquement aux utilisateurs authentifiés, définissez Action à exécuter quand une demande n’est pas authentifiée pour se connecter avec l’un des fournisseurs d’identité configurés. Pour s’authentifier mais ne pas limiter l’accès, définissez Action à exécuter quand une demande n’est pas authentifiée sur « Autoriser les requêtes anonymes (aucune action) ».

Fonctionnement

Architecture des fonctionnalités

Flux d’authentification

Comportement d’autorisation

Magasin de jetons

Journalisation et suivi

Architecture des fonctionnalités

Le composant intergiciel (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. Lorsqu’il est activé, chaque requête HTTP entrante le traverse avant d’être gérée par votre application.

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

• Authentifie les utilisateurs et les clients avec le ou les fournisseurs d’identité spécifiés
• Valide, stocke et actualise les jetons OAuth émis par le ou 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 et peut être configuré à l’aide des paramètres d’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. Lorsqu’il est activé, chaque requête HTTP entrante le traverse avant d’être gérée par votre application.

Architecture des fonctionnalités sur Linux avec conteneurs

Le module d’authentification et d’autorisation s’exécute dans un conteneur distinct, isolé du code de votre application. En utilisant ce que l’on appelle le Modèle ambassadeur, il interagit avec le trafic entrant pour effectuer des fonctionnalités similaires à celles de Windows. Comme il ne s’exécute pas in-process, aucune intégration directe avec des infrastructures de langage spécifiques n’est possible. Toutefois, les informations pertinentes dont votre application a besoin sont transmises à l’aide d’en-têtes de demande, comme expliqué ci-dessous.

Flux d’authentification

Le flux d’authentification est identique pour tous les fournisseurs, mais il diffère selon que vous souhaitez ou non vous connecter avec le Kit de développement logiciel (SDK) du fournisseur :

• Sans le Kit SDK du fournisseur : l’application délègue la connexion fédérée à App Service. C’est généralement le cas avec les applications de navigateur, qui peuvent présenter la page de connexion du fournisseur à l’utilisateur. C’est le code du serveur qui gère le processus de connexion, c’est pourquoi il est également appelé flux dirigé vers le serveur ou flux serveur. Ce cas s’applique aux applications de navigateur et aux applications mobiles qui utilisent un navigateur incorporé pour l’authentification.
• Avec le Kit SDK du fournisseur : l’application connecte manuellement les utilisateurs au fournisseur et soumet ensuite le jeton d’authentification à App Service pour validation. C’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. C’est le code de l’application qui gère le processus de connexion, c’est pourquoi il est également appelé flux dirigé vers le client ou flux client. Ce cas s’applique aux API REST, à Azure Functions et aux clients de navigateur JavaScript, ainsi qu’aux applications de navigateur nécessitant plus de souplesse dans le processus de connexion. Il concerne également les applications mobiles natives qui connectent les utilisateurs à l’aide du Kit SDK du fournisseur.

Les appels entre une application de navigateur approuvée dans App Service et une autre API REST dans App Service ou Azure Functions peuvent être authentifiés à l’aide du flux dirigé vers le serveur. Pour plus d’informations, consultez Personnaliser les connexions et les déconnexions.

Le tableau ci-dessous montre les étapes du flux d’authentification.

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 liens /.auth/login/<provider> pour leur permettre de se connecter à votre application à l’aide du fournisseur de leur choix.

Comportement d’autorisation

Dans le portail Azure, vous pouvez configurer App Service avec différents comportements lorsque la requête entrante n’est pas authentifiée. Les titres suivants décrivent les options possibles.

Autoriser les requêtes non authentifiées

Cette option permet de confier l’autorisation de trafic non authentifié à 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. Ce rejet peut être une action de redirection vers l’un des fournisseurs d’identité configurés. Dans ce cas, un client de navigateur est redirigé vers /.auth/login/<provider> pour le fournisseur de votre choix. Si la demande anonyme provient d’une application mobile native, la réponse retournée est HTTP 401 Unauthorized. Vous pouvez également faire en sorte que le rejet soit un message HTTP 401 Unauthorized ou HTTP 403 Forbidden pour toutes les requêtes.

Cette option évite d’avoir à écrire du code d’authentification dans l’application. Une autorisation plus fine, par exemple propre au rôle, peut être gérée en examinant les revendications de l’utilisateur (consultez la section Accéder aux revendications utilisateur).

Magasin de jetons

App Service fournit un magasin de jetons intégré : il s’agit d’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 le code de votre application doit accéder à des données de ces fournisseurs au nom de l’utilisateur, notamment :

• publier sur le fil d’actualité Facebook de l’utilisateur authentifié ;
• lire les données d’entreprise de l’utilisateur à l’aide de l’API Microsoft Graph

Il est en général nécessaire d’écrire du code pour recueillir, stocker et actualiser ces jetons dans votre application. 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, jetons d’accès et jetons d’actualisation sont mis en cache pour la session authentifiée et ne sont accessibles que par l’utilisateur associé.

Si vous n’avez pas besoin d’utiliser des jetons dans votre application, vous pouvez désactiver le magasin de jetons dans la page Authentification/autorisation de votre application.

Journalisation et suivi

Si vous activez la journalisation des applications, les traces de l’authentification et de l’autorisation apparaîtront directement dans les 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 échecs des demandes, vous saurez exactement quel rôle le module d’authentification et d’autorisation a pu jouer dans l’échec d’une demande. Dans les journaux d’activité de suivi, recherchez les références à un module nommé EasyAuthModule_32/64.

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

Lorsque vous utilisez Azure App Service avec une authentification simple derrière Azure Front Door ou d’autres proxys inverses, quelques éléments supplémentaires doivent être pris en compte.

1. Désactiver la mise en cache pour le workflow d’authentification

   Consultez Désactiver le cache pour le workflow d’authentification pour en savoir plus sur la configuration des règles dans Azure Front Door pour désactiver la mise en cache pour les pages d’authentification et d’autorisation.

2. Utiliser le point de terminaison Front Door pour les redirections

   App Service n’est généralement pas accessible directement lorsqu’il est exposé via Azure Front Door. Cela peut être évité, par exemple en exposant App Service via Private Link dans Azure Front Door Premium. Pour empêcher le workflow d’authentification de rediriger le trafic vers App Service directement, il est important de configurer l’application pour une redirection vers https://<front-door-endpoint>/.auth/login/<provider>/callback.

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

   Dans certaines configurations, App Service utilise le nom de domaine complet App Service comme URI de redirection au lieu du nom de domaine complet Front Door. Cela entraîne un problème lorsque le client est redirigé vers App Service au lieu de Front Door. Pour modifier cela, le paramètre forwardProxy doit être défini sur Standard pour qu’App Service respecte l’en-tête X-Forwarded-Host défini par Azure Front Door.

   D’autres proxys inverses comme Azure Application Gateway ou des produits tiers peuvent utiliser différents en-têtes et avoir besoin d’un autre paramètre forwardProxy.

   Cette configuration ne peut pas être effectuée via le portail Azure aujourd’hui et doit l’être via 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

   Mettre à jour les paramètres

   Rechercher

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

   et assurez-vous que convention est défini sur Standard pour respecter l’en-tête X-Forwarded-Host utilisé par Azure Front Door.

   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

Plus de ressources

• Procédure : Configurer votre application App Service ou Azure Functions pour utiliser une connexion Microsoft Entra
• Personnaliser les connexions et les déconnexions

• Utiliser des jetons et des sessions OAuth
• Revendications d’utilisateur et d’application
• Configuration basée sur des fichiers

Exemples :

• Tutoriel : Ajouter l’authentification à votre application web s’exécutant sur Azure App Service
• Tutoriel : Authentifier et autoriser les utilisateurs de bout en bout dans Azure App Service (Windows ou Linux)
• Intégration .NET Core d’Azure AppService EasyAuth (tiers)
• Obtenir une authentification Azure App Service fonctionnant avec .NET Core (tiers)