Types d’applications dans la version 1.0

Azure Active Directory (Azure AD) prend en charge l’authentification pour diverses architectures d’applications modernes, toutes basées sur des protocoles standard OAuth 2.0 ou OpenID Connect.

Le diagramme suivant illustre les scénarios et les types d’applications, ainsi que la façon dont différents composants peuvent être ajoutés :

Voici les cinq principaux scénarios d’application pris en charge par Azure AD :

• Application à page unique (SPA): un utilisateur doit s'authentifier dans une application à page unique sécurisée par Azure AD.
• navigateur web vers l’application web: un utilisateur doit se connecter à une application web sécurisée par Azure AD.
• application native à l’API web: une application native qui s’exécute sur un téléphone, une tablette ou un PC doit authentifier un utilisateur pour obtenir des ressources à partir d’une API web sécurisée par Azure AD.
• application web vers l’API web: une application web doit obtenir des ressources à partir d’une API web sécurisée par Azure AD.
• démon ou application serveur vers l’API web: application démon ou application serveur sans interface utilisateur web doit obtenir des ressources à partir d’une API web sécurisée par Azure AD.

Suivez les liens pour en savoir plus sur chaque type d’application et comprendre les scénarios généraux avant de commencer à utiliser le code. Vous pouvez également en savoir plus sur les différences que vous devez connaître lors de l’écriture d’une application particulière qui fonctionne avec le point de terminaison v1.0 ou le point de terminaison v2.0.

Vous pouvez développer l’une des applications et scénarios décrits ici à l’aide de différents langages et plateformes. Ils sont tous soutenus par des exemples de code complets disponibles dans le guide des exemples de code : v1.0 exemples de code par scénario et exemples de code v2.0 par scénario. Vous pouvez également télécharger les exemples de code directement à partir des exemples de référentiels GitHub correspondants .

En outre, si votre application a besoin d’une partie ou d’un segment spécifique d’un scénario de bout en bout, dans la plupart des cas, cette fonctionnalité peut être ajoutée indépendamment. Par exemple, si vous avez une application native qui appelle une API web, vous pouvez facilement ajouter une application web qui appelle également l’API web.

Inscription d’application

Inscription d’une application qui utilise le point de terminaison Azure AD v1.0

Toute application qui externalise l’authentification auprès d’Azure AD doit être inscrite dans un annuaire. Cette étape implique d’informer Azure AD de votre application, notamment l’URL où elle se trouve, l’URL où envoyer les réponses après l’authentification, l’URI qui permet d'identifier votre application, etc. Ces informations sont requises pour quelques raisons clés :

• Azure AD doit communiquer avec l’application lors de la gestion de l’authentification ou de l’échange de jetons. Les informations transmises entre Azure AD et l’application incluent les éléments suivants :

  • 'URI d’ID d’application : identificateur d’une application. Cette valeur est envoyée à Azure AD pendant l’authentification pour indiquer l’application pour laquelle l’appelant souhaite un jeton. De plus, cette valeur est incluse dans le jeton afin que l’application sache qu’elle était la cible prévue.
  • URL de réponse et URI de redirection : pour une API web ou une application web, l’URL de réponse est l’emplacement où Azure AD envoie la réponse d’authentification, y compris un jeton si l’authentification a réussi. Pour une application native, l’URI de redirection est un identificateur unique vers lequel Azure AD redirige l’agent utilisateur dans une requête OAuth 2.0.
  • 'ID d’application - ID d’une application, généré par Azure AD lorsque l’application est inscrite. Lors de la demande d’un code d’autorisation ou d’un jeton, l’ID d’application et la clé sont envoyés à Azure AD pendant l’authentification.
  • clé : clé envoyée avec un ID d’application lors de l’authentification auprès d’Azure AD pour appeler une API web.

• Azure AD doit s’assurer que l’application dispose des autorisations requises pour accéder à vos données d’annuaire, à d’autres applications de votre organisation, et ainsi de suite.

Pour en savoir plus, découvrez comment inscrire une application.

Applications monolocataires et multilocataires

L’approvisionnement devient plus clair quand vous comprenez qu’il existe deux catégories d’applications qui peuvent être développées et intégrées à Azure AD :

• application à locataire unique : une application à locataire unique est destinée à être utilisée dans une organisation. Il s’agit généralement d’applications métier écrites par un développeur d’entreprise. Une application à locataire unique doit uniquement être accessible par les utilisateurs d’un seul annuaire et, par conséquent, elle doit uniquement être provisionnée dans un seul annuaire. Ces applications sont généralement inscrites par un développeur dans l’organisation.
• application multilocataire : une application multilocataire est destinée à être utilisée dans de nombreuses organisations, pas seulement dans une seule organisation. Il s’agit généralement d’applications SaaS (software-as-a-service) écrites par un éditeur de logiciels indépendant. Les applications mutualisées doivent être approvisionnées dans chaque annuaire où elles seront utilisées, ce qui nécessite le consentement de l’utilisateur ou de l’administrateur pour les inscrire. Ce processus de consentement démarre quand une application a été enregistrée dans l’annuaire et accède à l’API Graph ou à une autre API web. Lorsqu’un utilisateur ou un administrateur d’une autre organisation s’inscrit pour utiliser l’application, une boîte de dialogue affiche les autorisations requises par l’application. L’utilisateur ou l’administrateur peut ensuite donner son consentement à l’application, ce qui donne à l’application l’accès aux données indiquées, puis inscrit l’application dans son annuaire. Pour plus d’informations, consultez Vue d’ensemble de l’infrastructure de consentement.

Considérations supplémentaires lors du développement d’applications à environnement monolocataire ou multitenant

Certaines considérations supplémentaires se produisent lors du développement d’une application mutualisée au lieu d’une application à locataire unique. Par exemple, si vous mettez votre application à la disposition des utilisateurs dans plusieurs annuaires, vous avez besoin d’un mécanisme pour déterminer le tenant auquel ils appartiennent. Une application à locataire unique doit uniquement rechercher dans son propre répertoire pour un utilisateur, tandis qu’une application multilocataire doit identifier un utilisateur spécifique à partir de tous les répertoires dans Azure AD. Pour accomplir cette tâche, Azure AD fournit un point de terminaison d’authentification commun où toute application multilocataire peut diriger les demandes de connexion, au lieu d’un point de terminaison spécifique au locataire. Ce point de terminaison est https://login.microsoftonline.com/common pour tous les répertoires dans Azure AD, tandis qu’un point de terminaison spécifique au locataire peut être https://login.microsoftonline.com/contoso.onmicrosoft.com. Le point de terminaison commun est particulièrement important à prendre en compte lors du développement de votre application, car vous aurez besoin de la logique requise pour gérer plusieurs locataires lors de l'authentification, la validation des jetons et la déconnexion.

Si vous développez actuellement une application à locataire unique, mais que vous souhaitez la rendre disponible pour de nombreuses organisations, vous pouvez facilement apporter des modifications à l’application et à sa configuration dans Azure AD pour la rendre compatible avec plusieurs locataires. En outre, Azure AD utilise la même clé de signature pour tous les jetons de tous les répertoires, que l’authentification soit fournie dans une application monolocataire ou multilocataire.

Chaque scénario répertorié dans ce document comprend une sous-section qui décrit ses exigences d’approvisionnement. Pour plus d’informations détaillées sur l’approvisionnement d’une application dans Azure AD et les différences entre les applications monolocataires et multilocataires, consultez Intégration d’applications à Azure Active Directory pour plus d’informations. Poursuivez la lecture pour comprendre les scénarios d’application courants dans Azure AD.

Étapes suivantes

• En savoir plus sur les autres principes de base de l’authentification azure AD