Développement d’applications Microsoft Entra

  • 3 minutes

Maintenant que vous vous êtes familiarisé avec les principes de base et les avantages du service Microsoft Entra ID, vous devez déterminer comment vous pouvez utiliser ses fonctionnalités pour implémenter l’authentification et l’autorisation pour votre application. Vous vous rendez compte que, pour aider à sécuriser les données de vos clients, vous devez vous assurer que votre implémentation s’intègre aux mécanismes de contrôle d’accès PostgreSQL. Vous avez décidé de commencer par identifier les tâches impliquées dans le développement, le déploiement et la gestion des applications Microsoft Entra. Vous souhaitez également déterminer comment vous pouvez répondre à la nécessité de fournir un accès à votre application à plusieurs clients.

Pour implémenter des applications basées sur Microsoft Entra ID, vous devez effectuer plusieurs tâches de gestion liées aux applications, y compris l’inscription, la configuration de ses autorisations et la gestion de ses secrets.

Qu’est-ce que l’inscription d’application ?

Dans un environnement Microsoft Entra, un utilisateur s’authentifie auprès d’une application en deux étapes :

  1. Tout d’abord, Microsoft Entra ID vérifie l’identité de l’utilisateur. Une fois l’authentification réussie, Microsoft Entra ID émet des jetons qui contiennent des informations reflétant la réussite de l’authentification.
  2. L’utilisateur passe ces jetons à l’application. L’application valide les jetons de sécurité de l’utilisateur pour vérifier que l’authentification a réussi.

Pour effectuer cette validation, l’application doit être en mesure de communiquer en toute sécurité avec Microsoft Entra ID. Cela nécessite que l’application elle-même fonctionne comme un principal de sécurité Microsoft Entra. Pour y parvenir, vous devez vous assurer que l’application est représentée dans le même locataire Microsoft Entra que celui qui contient le compte de l’utilisateur qui tente de s’authentifier.

Dans Microsoft Entra ID, une application peut avoir deux représentations :

  • L’objet d’application, qui définit les propriétés de l’application.
  • Le principal de service, qui fournit des fonctionnalités d’authentification et d’autorisation, et fait référence à l’objet d’application.

Vous pouvez créer des objets d’application directement dans le Portail Azure à partir du volet Inscriptions d’applications. Pour vos propres applications personnalisées, l’inscription crée automatiquement le principal de service correspondant. Ensuite, vous pouvez gérer les principaux de service dans le Portail Azure à partir du volet Applications d’entreprise.

Lors de l’inscription de l’application, vous avez la possibilité de spécifier l’URI (Uniform Resource Identifier) de redirection de l’application. Il désigne l’emplacement vers lequel le serveur d’autorisation redirige l’utilisateur une fois que l’application a été autorisée avec succès. Le serveur d’autorisation envoie le code ou le jeton à l’URI de redirection. Il est donc important que vous inscriviez l’emplacement qui convient dans le cadre du processus d’inscription de l’application.

Notes

L’URI de redirection doit commencer par https, sauf s’il fait référence au localhost, dans ce cas, vous pouvez utiliser http://localhost. Par ailleurs, la casse doit être respectée.

Que sont les autorisations d’application ?

Les applications qui s’intègrent à Microsoft Entra ID suivent un modèle d’autorisation qui vous permet de contrôler de manière granulaire ses autorisations sur d’autres ressources et applications intégrées à Microsoft Entra. Microsoft Entra ID s’appuie sur le modèle d’autorisation OAuth 2.0 pour implémenter ces autorisations. Dans OAuth 2.0, les autorisations sont organisées en ensembles, communément appelés étendues.

En tant que développeur, vous demandez les autorisations dont votre application a besoin en spécifiant une chaîne d’autorisation lors de sa configuration. Par exemple, en définissant la chaîne d’autorisation sur « https://graph.microsoft.com/Calendars.Read" », vous indiquez que l’application doit pouvoir lire les calendriers des utilisateurs dans Microsoft Graph. Les autorisations doivent être accordées à l’application par le biais d’un consentement, qui doit être accordé par un utilisateur ou un administrateur Microsoft Entra, en fonction de l’étendue de ces autorisations.

Microsoft Entra ID prend en charge deux types de permissions :

  • Les autorisations déléguées sont utilisées par les applications interactives pour lesquelles un utilisateur est connecté. Par conséquent, l’application agit au nom d’un utilisateur connecté lorsqu’elle accède à la ressource cible.
  • Les autorisations d’application sont utilisées par les applications qui s’exécutent sans qu’un utilisateur soit connecté (les services en arrière-plan, par exemple). Ces applications nécessitent un consentement administratif.

Que sont les secrets d’application ?

Il existe deux types d’authentification disponibles pour les principaux de service :

  • L’authentification par mot de passe s’appuie sur les secrets d’application que vous pouvez générer directement dans le Portail Azure. Lorsque vous générez un secret, vous spécifiez sa durée de vie.
  • L’authentification basée sur les certificats s’appuie sur les certificats que vous téléchargez sur Microsoft Entra ID.

Remarque

Si votre application est hébergée par une ressource de calcul Azure, telle qu’une machine virtuelle Azure, une application web Azure App Service ou un cluster AKS, et que vous n’utilisez pas de principaux de service, envisagez d’utiliser des identités managées pour votre identité d’application. Cela élimine la nécessité de gérer les mots de passe ou les certificats pour l’authentification.

Quels sont les différents types de scénarios d’authentification d’application ?

Le flux d’authentification et les détails de configuration correspondants dépendent du type d’application. Les catégories courantes de types d’applications sont les suivantes :

  • Applications basées sur un navigateur. Il s’agit d’applications web dans lesquelles les jetons sont acquis par une application JavaScript ou TypeScript qui s’exécute dans le navigateur. Ces applications utilisent souvent une infrastructure comme Angular, React ou Vue. MSAL.js est la seule bibliothèque d’authentification Microsoft qui prend en charge les applications monopages.
  • Applications clientes publiques. Il s’agit d’applications qui s’appuient toujours sur les utilisateurs connectés pour obtenir des jetons. Ces applications incluent les applications de bureau et mobiles qui appellent des API web pour le compte des utilisateurs connectés.
  • Applications clientes confidentielles. Elles obtiennent des jetons elles-mêmes. Les applications de cette catégorie incluent les applications web qui appellent une API web, les API web qui appellent une autre API web, les démons Linux et les services Windows.

Les deux premiers éléments ci-dessus authentifient un utilisateur, tandis que le troisième authentifie uniquement une application ou un service entre l’utilisateur et un service principal. Dans ce cas, le service principal ne connaît rien sur l’utilisateur final, mais il connaît l’application qui l’utilise. Imaginez par exemple, une application qui utilise Azure Maps comme un service principal. Le service Maps doit savoir qu’une application autorisée l’appelle pour que la facturation soit correcte, mais il n’a pas besoin de connaître quoi que ce soit sur l’utilisateur final.

Quelle est la différence entre les applications Microsoft Entra à locataire unique et les applications multi-locataires ?

En tant que développeur, vous pouvez choisir de configurer votre application pour qu’elle soit à locataire unique ou multi-locataire lorsque vous procédez à son inscription :

  • les applications à locataire unique ne sont disponibles que dans le locataire dans lequel elles ont été inscrites, également appelé leur locataire de base.
  • Les applications multi-locataires sont accessibles aux utilisateurs dans leur locataire de base et d’autres locataires Microsoft Entra.

Si vous utilisez le Portail Azure pour inscrire l’application, vous devez spécifier l’emplacement de l’application en définissant sa propriété audience sur l’une des valeurs suivantes :

  • Comptes dans ce répertoire uniquement. On obtient ainsi une configuration à locataire unique. En effet, cela vous permet d’accorder l’accès à l’application à n’importe quel principal de sécurité de votre locataire, y compris les comptes invités.
  • Comptes dans n’importe quel répertoire Microsoft Entra. On obtient une configuration multi-locataire. Cela permet aux utilisateurs en dehors de votre organisation d’inscrire l’application dans leurs propres locataires Microsoft Entra.
  • Comptes dans n’importes quels répertoires Microsoft Entra et comptes Microsoft personnels (Skype, Xbox, Outlook.com). Cette propriété entraîne également une configuration multi-locataire, mais permet aux utilisateurs disposant de comptes Microsoft personnels d’utiliser l’application.

Remarque

Un objet d’application existe uniquement dans le locataire de base, mais dans le cas de la configuration multi-locataire, il peut être référencé par plusieurs principaux de service sur différents locataires Microsoft Entra.