Explorer l’authentification et l’autorisation dans App Service

6 minutes

Azure App Service offre une prise en charge intégrée de l’authentification et de l’autorisation, 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, votre back-end mobile et dans Azure Functions.

Pourquoi utiliser l’authentification intégrée ?

Il n’est pas obligatoire d’utiliser App Service pour l’authentification et l’autorisation. Plusieurs infrastructures web sont fournies avec des fonctionnalités de sécurité ; vous pouvez les utiliser si vous le souhaitez. Si vous avez besoin de plus de flexibilité que n’en offre App Service, vous pouvez également écrire vos propres utilitaires.

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 de code.
Vous pouvez intégrer à plusieurs fournisseurs de connexion, Par exemple, Microsoft Entra ID, Facebook, Google, X.

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
Plateforme d’identité Microsoft	`/.auth/login/aad`	Connexion App Service à la plateforme d’identités Microsoft
Facebook	`/.auth/login/facebook`	Connexion App Service à Facebook
Google	`/.auth/login/google`	Connexion App Service à Google
X	`/.auth/login/twitter`	Ouverture de session X App Service
Tout fournisseur OpenID Connect	`/.auth/login/<providerName>`	Connexion App Service à OpenID Connect
GitHub	`/.auth/login/github`	Connexion GitHub App Service

Lorsque l’authentification et l’autorisation sont activées 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.

Fonctionnement

Le module d’authentification et d’autorisation s’exécute dans le même bac à sable que le code de l’application. Lorsqu’il est activé, chaque requête HTTP entrante le traverse avant d’être géré par le code de l’application. Ce module gère plusieurs choses 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.

Notes

Dans Linux et les conteneurs, le module d’authentification et d’autorisation s’exécute dans un conteneur distinct, isolé du code de votre application. Comme il ne s’exécute pas en cours de processus, aucune intégration directe avec des frameworks de langage spécifiques n'est possible.

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 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.
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. Cela s’applique aux API REST, à Azure Functions, aux clients de navigateur JavaScript et aux applications mobiles natives qui connectent les utilisateurs à l’aide du Kit de développement logiciel (SDK) du fournisseur.

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

Étape	Sans le Kit SDK du fournisseur	Avec le Kit SDK du fournisseur
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.
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.
É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.
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` (géré automatiquement par les Kits SDK clients Mobile Apps).

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 de nombreux comportements quand la requête entrante n’est pas authentifiée.

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. Il vous permet de présenter plusieurs fournisseurs de connexion à vos utilisateurs.
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.

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.

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.

Journalisation et suivi

Si vous activez la journalisation des applications, les traces de l’authentification et de l’autorisation sont collectées 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.

Continuer