Partage via

Authentification et autorisation dans Azure App Service et Azure Functions

  • Article

Remarque

Depuis le 1er juin 2024, toutes les applications App Service nouvellement créées ont la possibilité de générer un nom d’hôte par défaut unique en utilisant la convention d’affectation de noms <app-name>-<random-hash>.<region>.azurewebsites.net. Les noms d’application existants restent inchangés.

Exemple : myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Pour plus d’informations, reportez-vous à Nom d’hôte par défaut unique pour les ressources App Service.

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, Facebook, Google, 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 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 :

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 Ouverture de session X App Service
GitHub /.auth/login/github Connexion GitHub App Service
Se connecter avec Apple /.auth/login/apple App Service Se connecter avec une connexion Apple (préversion)
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 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. Les restrictions d’accès peuvent être définies dans la section Authentification>Paramètres d’authentification de votre application web. 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) ».

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. 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.

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.

Un diagramme d’architecture montrant les demandes interceptées par un processus dans le bac à sable de site qui interagit avec les fournisseurs d’identité avant d’autoriser le trafic vers le site déployé

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.

Étape Sans le Kit SDK du fournisseur Avec le Kit SDK du fournisseur
1. Connexion de l’utilisateur Redirige le client vers /.auth/login/<provider>. Le code client connecte directement l’utilisateur avec le Kit SDK du fournisseur et reçoit un jeton d’authentification. Pour plus d’informations, consultez la documentation du fournisseur.
2. Post-authentification Le fournisseur redirige le client vers /.auth/login/<provider>/callback. Le code client publie un jeton du fournisseur vers /.auth/login/<provider> pour validation.
3. Établissement de la 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 le cookie d’authentification dans les demandes suivantes (gérées 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 liens /.auth/login/<provider> pour leur permettre de se connecter à votre application à l’aide du fournisseur de leur choix.

Comportement d’autorisation

Important

Cette fonctionnalité fournit uniquement l’authentification par défaut, pas l’autorisation. Votre application peut encore avoir besoin de prise des décisions d’autorisation, en plus des vérifications que vous configurez ici.

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.

Restreindre l’accès

  • Autoriser les demandes non authentifiées : cette option diffère l’autorisation du trafic non authentifié dans le code de votre 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. L’action spécifique à entreprendre est spécifiée dans la section Demandes non authentifiées.

    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).

    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.

    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.

Demandes non authentifiées

  • Redirection HTTP 302 Found : recommandé pour les sites web, redirige l’action 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.
  • HTTP 401 Unauthorized : 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 pour toutes les requêtes.
  • HTTP 403 Forbidden configure le rejet en tant que HTTP 403 Forbidden pour toutes les requêtes.
  • HTTP 404 Not found configure le rejet en tant que HTTP 404 Not found pour toutes les requêtes.

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.

Atténuation de la falsification de requête intersites

L’authentification App Service atténue la falsification de requête intersites (CSRF, Cross Site Request Forgery) en inspectant les requêtes clientes à la recherche des conditions suivantes :

  • Il s’agit d’une requête POST qui s’est authentifiée à l’aide 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 des 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 redirections dans 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 une authentification derrière Azure Front Door ou d’autres proxys inverses, quelques éléments supplémentaires doivent être pris en compte.

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

  • 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.

  • 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

Exemples :