Partager via


Modèle d’application

Les applications peuvent connecter des utilisateurs eux-mêmes ou déléguer la connexion à un fournisseur d’identité. Cet article décrit les étapes requises pour inscrire une application auprès de la plateforme d’identités Microsoft.

Inscrire une application

Pour qu’un fournisseur d’identité sache qu’un utilisateur a accès à une application particulière, l’utilisateur et l’application doivent être inscrits auprès du fournisseur d’identité. Lorsque vous inscrivez votre application avec l’ID Microsoft Entra, vous fournissez une configuration d’identité pour votre application qui lui permet de s’intégrer à la plateforme d’identités Microsoft. L’inscription de l’application vous permet également de :

  • Personnaliser la marque de votre application dans boîte de dialogue de connexion. Cette personnalisation est importante, car la connexion est la première expérience qu’un utilisateur aura avec votre application.
  • Décidez si vous souhaitez autoriser les utilisateurs à se connecter uniquement s’ils appartiennent à votre organisation. Cette architecture est appelée application monolocataire. Vous pouvez également autoriser les utilisateurs à se connecter à l’aide de n’importe quel compte professionnel ou scolaire, appelé application multilocataire. Vous pouvez également autoriser des comptes Microsoft personnels ou un compte social à partir de LinkedIn, Google, et ainsi de suite.
  • Demander des autorisations d’étendue. Par exemple, vous pouvez demander l’étendue « user.read », qui accorde l’autorisation de lire le profil de l’utilisateur connecté.
  • Définissez des étendues qui définissent l’accès à votre API web. En règle générale, lorsqu’une application souhaite accéder à votre API, elle doit demander des autorisations aux étendues que vous définissez.
  • Partagez un secret avec la plateforme d’identités Microsoft qui prouve l’identité de l’application. L’utilisation d’un secret est pertinente dans le cas où l’application est une application cliente confidentielle. Une application cliente confidentielle est une application qui peut contenir des informations d’identification de manière sécurisée, comme un client web. Un serveur principal approuvé est requis pour stocker les informations d’identification.

Une fois l’application inscrite, elle reçoit un identificateur unique qu’elle partage avec la plateforme d’identités Microsoft lorsqu’elle demande des jetons. Si l’application est une application cliente confidentielle, elle partage également le secret ou la clé publique selon que des certificats ou des secrets ont été utilisés.

La plateforme d’identités Microsoft représente des applications à l’aide d’un modèle qui remplit deux fonctions principales :

  • Identifiez l’application par les protocoles d’authentification qu’elle prend en charge.
  • Fournissez tous les identificateurs, URL, secrets et informations associées nécessaires à l’authentification.

Plateforme d’identités Microsoft :

  • Contient toutes les données requises pour prendre en charge l’authentification au moment de l’exécution.
  • Contient toutes les données pour décider des ressources auxquelles une application peut avoir besoin d’accéder, et dans quelles circonstances une demande donnée doit être remplie.
  • Fournit une infrastructure pour implémenter l’approvisionnement de l’application au sein du locataire de son développeur et de tout autre locataire Microsoft Entra.
  • Gère le consentement de l'utilisateur lors de la demande de jeton et facilite l'approvisionnement dynamique d'applications entre différentes entités locataires.

Le consentement est le processus d’octroi d’une autorisation de propriétaire de ressource pour une application cliente d’accéder aux ressources protégées, sous des autorisations spécifiques, au nom du propriétaire de la ressource. La plateforme d’identités Microsoft active :

  • Les utilisateurs et les administrateurs doivent accorder ou refuser dynamiquement le consentement de l’application pour accéder aux ressources en leur nom.
  • Les administrateurs décident finalement quelles applications sont autorisées à faire et quels utilisateurs peuvent utiliser des applications spécifiques, ainsi que la façon dont les ressources d’annuaire sont accessibles.

Applications multilocataires

Importante

Les applications multilocataires ne fonctionnent pas au-delà des limites du cloud en raison de la séparation des autorités de principal de service au sein de chaque cloud. Par exemple, si l’objet d’application est hébergé dans le cloud commercial, le principal de service associé est créé localement lors de l’intégration du client. Ce processus échoue lors de la traversée des limites cloud, car les URL d’autorité diffèrent (par exemple, par exemple, .com vs. .us), provoquant une incompatibilité.

Dans la plateforme d’identités Microsoft, un objet d’application décrit une application. Au moment du déploiement, la plateforme d’identités Microsoft utilise l’objet d’application comme blueprint pour créer un principal de service, qui représente une instance concrète d’une application au sein d’un répertoire ou d’un locataire. Le principal de service définit ce que l’application peut réellement faire dans un répertoire cible spécifique, qui peut l’utiliser, les ressources auxquelles elle a accès, et ainsi de suite. La plateforme d’identités Microsoft crée un principal de service à partir d’un objet d’application par le biais du consentement.

Le diagramme suivant montre un flux d’approvisionnement simplifié de la plateforme d’identités Microsoft piloté par le consentement. Il affiche deux locataires : A et B.

  • Le client A est propriétaire de l’application.
  • Le locataire B instancie l’application via un principal de service.

Diagramme montrant un flux d’approvisionnement simplifié piloté par le consentement.

Dans ce flux d’approvisionnement :

  1. Un utilisateur du locataire B tente de se connecter avec l’application. Le point de terminaison d’autorisation demande un jeton pour l’application.
  2. Les informations d’identification de l’utilisateur sont acquises et vérifiées pour l’authentification.
  3. L’utilisateur est invité à fournir son consentement pour que l’application accède à l’entité B.
  4. La plateforme d’identités Microsoft utilise l’objet d’application dans le locataire A comme modèle pour créer un principal de service dans le locataire B.
  5. L’utilisateur reçoit le jeton demandé.

Vous pouvez répéter ce processus pour d’autres locataires. Le locataire A conserve le blueprint de l’application (objet d’application). Les utilisateurs et les administrateurs de tous les autres locataires où l’application reçoit le consentement conservent le contrôle sur ce que l’application est autorisée à faire via l’objet principal de service correspondant dans chaque locataire. Pour plus d’informations, consultez les objets d'application et de service principal de la plateforme d’identités de Microsoft.

Étapes suivantes

Pour plus d’informations sur l’authentification et l’autorisation dans la plateforme d’identités Microsoft, consultez les articles suivants :

Pour plus d’informations sur le modèle d’application, consultez les articles suivants :