Configurer une application OpenID Connect OAuth à partir de la galerie d’applications Microsoft Entra
Processus d’ajout d’une application OpenID à partir de la galerie
Connectez-vous au Centre d’administration de Microsoft Entra au minimum en tant qu’Administrateur d’application cloud.
Accédez à Identité>Applications>Applications d’entreprise.
Sélectionnez Nouvelle application en haut de la boîte de dialogue.
Dans la zone de recherche, tapez le nom de l’application. Dans le panneau de résultats, sélectionnez l’application souhaitée et inscrivez-vous à l’application.
Dans la page Nom de l’application, cliquez sur le bouton S’inscrire.
Notes
L’administrateur des locataires doit sélectionner le bouton S’inscrire et donner son consentement pour l’application. L’application est alors ajoutée au tenant externe, où vous pouvez effectuer les configurations. Il est inutile d’ajouter l’application explicitement.
Vous êtes redirigé vers la page Connexion de l’application ou Microsoft Entra ID pour entrer les informations d’identification de connexion.
Une fois que l’authentification a été effectuée, vous acceptez le consentement dans la page de consentement. La page d’accueil de l’application s’affiche.
Notes
Vous ne pouvez ajouter qu’une instance de l’application. Si vous en avez déjà ajouté une et que vous avez tenté de fournir une nouvelle fois le consentement, l’application n’est pas ajoutée à nouveau dans le locataire. Vous ne pouvez donc utiliser en toute logique qu’une seule instance de l’application dans le locataire.
Suivez la vidéo ci-dessous pour ajouter une application OpenID à partir de la galerie.
Flux d’authentification à l’aide d’OpenID Connect
Le flux d’authentification le plus élémentaire comprend les étapes suivantes :
Application mutualisée
Une application mutualisée est destinée à être utilisée dans plusieurs organisations, et pas dans une seule. 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 répertoire où elles seront utilisées. Leur inscription nécessite le consentement de l’utilisateur ou de l’administrateur. 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 contenant les autorisations nécessaires à l’application s’affiche.
L’utilisateur ou l’administrateur peut alors donner son consentement pour l’application. Le consentement permet à l’application d’accéder aux données indiquées, et enregistre l’application dans le répertoire.
Notes
Si vous mettez votre application à la disposition des utilisateurs dans plusieurs répertoires, vous devez disposer d’un mécanisme permettant de déterminer le locataire dans lequel ils se trouvent. Une application à locataire unique ne doit regarder que dans son propre répertoire pour y rechercher un utilisateur. Une application mutualisée doit identifier un utilisateur spécifique dans tous les répertoires de Microsoft Entra ID.
À cet effet, Microsoft Entra ID fournit un point de terminaison d’authentification commun vers lequel une application mutualisée peut diriger les requêtes de connexion, plutôt que vers un point de terminaison propre au locataire. Ce point de terminaison est https://login.microsoftonline.com/common pour tous les répertoires dans Microsoft Entra ID. Un point de terminaison propre à un locataire peut être https://login.microsoftonline.com/contoso.onmicrosoft.com.
Il est important de tenir compte du point de terminaison commun lorsque vous développez votre application. Vous avez besoin de la logique nécessaire pour gérer plusieurs locataires pendant la connexion, la déconnexion et la validation des jetons.
Par défaut, Microsoft Entra ID promeut les applications mutualisées. Elles sont facilement accessibles entre les organisations et d’une utilisation simple une fois que vous en avez accepté le consentement.
Framework de consentement
Vous pouvez utiliser l’infrastructure de consentement de Microsoft Entra pour développer des applications clientes natives et web mutualisées. Ces applications autorisent la connexion au moyen de comptes d’utilisateurs d’un locataire Microsoft Entra différent de celui où l’application a été inscrite. Elles peuvent également avoir besoin d’accéder à des API web, par exemple :
- API Microsoft Graph pour accéder à Microsoft Entra ID, à Intune et aux services de Microsoft 365.
- API des autres services Microsoft
- Vos propres API web
L’infrastructure est basée sur le consentement d’un utilisateur ou d’un administrateur à l’inscription d’une application dans son répertoire. Cette inscription peut impliquer l’accès aux données de répertoire. Une fois le consentement donné, l’application cliente peut appeler l’API Microsoft Graph au nom de l’utilisateur et utiliser les informations en fonction des besoins.
L’API Microsoft Graph permet d’accéder aux données de Microsoft 365, par exemple :
- Calendriers et messages d’Exchange
- Sites et listes de SharePoint
- Documents de OneDrive
- Blocs-notes de OneNote
- Tâches du Planificateur
- Classeurs d’Excel
L’API Graph fournit également un accès aux utilisateurs et groupes de Microsoft Entra ID et aux autres objets de données provenant d’autres services de cloud Microsoft.
Les étapes suivantes vous montrent comment l’expérience de consentement fonctionne pour le développeur d’applications et pour l’utilisateur :
Supposons que l’une de vos applications clientes web doive demander des autorisations spécifiques pour accéder à une ressource ou à une API. Le Portail Azure est utilisé pour déclarer les demandes d’autorisation au moment de la configuration. Comme d’autres paramètres de configuration, elles sont incluses dans les inscriptions Microsoft Entra de l’application. Pour le chemin des demandes d’autorisations, vous devez effectuer les étapes ci-dessous :
a. Cliquez sur Inscriptions d’applications à gauche du menu et ouvrez votre application en tapant son nom dans la zone de recherche.
b. Cliquez sur Afficher les autorisations de l’API.
c. Cliquez sur Ajouter une autorisation.
d. Cliquez sur Microsoft Graph.
e. Sélectionnez les options appropriées dans Autorisations déléguées et Autorisations d’application.
Considérez que les autorisations de votre application ont été mises à jour. L’application est en cours d’exécution, et un utilisateur s’apprête à l’utiliser pour la première fois. L’application doit tout d’abord obtenir un code d’autorisation du point de terminaison /authorize de Microsoft Entra ID. Le code d’autorisation peut ensuite être utilisé pour obtenir un nouvel accès et un jeton d’actualisation.
Si l’utilisateur n’est pas déjà authentifié, le point de terminaison /authorize de Microsoft Entra ID l’invite à se connecter.
Une fois l’utilisateur connecté, Microsoft Entra ID détermine s’il est nécessaire d’afficher une page de consentement pour l’utilisateur. La détermination est différente selon que l’utilisateur (ou l’administrateur de son organisation) a déjà accordé ou non son consentement à l’application.
Si le consentement n’a pas été accordé, Microsoft Entra invite l’utilisateur à le fournir et affiche les autorisations requises pour le fonctionnement. Les autorisations qui s’affichent dans la boîte de dialogue de consentement correspondent à celles qui sont sélectionnées dans les autorisations déléguées.
Un utilisateur standard peut donner son consentement pour certaines autorisations. D’autres autorisations nécessitent le consentement de l’administrateur d’un locataire.
Différence entre le consentement administrateur et le consentement de l’utilisateur
En tant qu’administrateur, vous pouvez également donner votre consentement pour les autorisations déléguées d’une application pour le compte de tous les utilisateurs de votre client. Le consentement administrateur évite que la boîte de dialogue de consentement ne s’affiche pour tous les utilisateurs du locataire. Les utilisateurs disposant du rôle d’administrateur peuvent indiquer leur consentement. Dans la page Paramètres de l’application, sélectionnez Autorisations requises>Accorder le consentement administrateur.
Notes
Pour les applications monopage (SPA) qui utilisent MSAL.js, vous devez maintenant accorder un consentement explicite à l’aide du bouton Accorder le consentement administrateur. Sinon, l’application échoue lorsque le jeton d’accès est demandé.
Les autorisations d’application uniquement nécessitent toujours le consentement de l’administrateur d’un locataire. Si votre application demande une autorisation application seule et qu’un utilisateur tente de se connecter à l’application, un message d’erreur s’affiche. Le message indique que l’utilisateur n’est pas en mesure de donner son consentement.
Si votre application utilise des autorisations qui nécessitent un consentement administrateur, vous devez y intégrer une option comme un bouton ou un lien afin que l’administrateur puisse démarrer l’action. La requête que votre application envoie pour cette action est une demande d’autorisation OAuth2/OpenID Connect ordinaire. Cette requête inclut le paramètre de chaîne de requête prompt=admin_consent.
Une fois que l’administrateur a donné son consentement et que le principal de service est créé dans le locataire du client, les demandes de connexion ultérieures n’ont pas besoin du paramètre prompt=admin_consent. Comme l’administrateur a décidé que les autorisations demandées sont acceptables, les autres utilisateurs du locataire n’ont plus à donner leur consentement par la suite.
L’administrateur d’un client peut empêcher les utilisateurs standard de donner son consentement aux applications. Si cette fonctionnalité est désactivée, le consentement de l’administrateur est toujours requis pour que l’application soit utilisée dans le client. Si vous souhaitez tester votre application avec le consentement de l’utilisateur final désactivé, vous trouverez le commutateur de configuration dans le portail Azure. Il se trouve dans la section Paramètres utilisateur sous Applications d’entreprise.
Le paramètre prompt=admin_consent peut également être utilisé par les applications qui demandent des autorisations ne nécessitant pas le consentement de l’administrateur. Exemple d’application qui requiert une expérience : l’administrateur des locataires « s’inscrit » une fois et aucun autre utilisateur n’est invité à donner son consentement à compter de ce moment.
Imaginez qu’une application nécessite un consentement administrateur, et qu’un administrateur se connecte sans envoyer le paramètre prompt=admin_consent. Si l’administrateur donne son consentement pour l’application, celui-ci s’applique uniquement pour son compte d’utilisateur. Les utilisateurs standard ne peuvent toujours pas se connecter ni donner leur consentement pour l’application. Cette fonctionnalité s’avère particulièrement utile si vous souhaitez donner à l’administrateur des locataires la possibilité d’explorer votre application avant d’autoriser l’accès à d’autres utilisateurs.