Expérience de consentement pour les applications dans Microsoft Entra ID

Dans cet article, vous découvrez l'expérience utilisateur de consentement pour les applications dans Microsoft Entra. Vous pouvez ainsi gérer de manière intelligente des applications pour votre organisation et/ou développer des applications avec une expérience de consentement plus transparente.

Le consentement est le processus via lequel un utilisateur autorise une application à accéder à des ressources protégées en son nom. Un administrateur ou un utilisateur peut être invité à donner son consentement pour autoriser l’accès à ses données personnelles/professionnelles.

L'expérience utilisateur réelle d'octroi du consentement varie selon les stratégies définies au niveau du client de l'utilisateur, le niveau d'autorité (ou rôle) de l'utilisateur et le type d'autorisation demandé par l'application cliente. Cela signifie que les développeurs d’applications et les administrateurs de locataires contrôlent certains aspects de l’expérience de consentement. Les administrateurs ont la possibilité de configurer et de désactiver des stratégies au niveau d’un locataire ou d’une application afin de contrôler l’expérience de consentement au sein de leur locataire. Les développeurs d’applications peuvent dicter les types d’autorisations demandés. Ils peuvent également décider s’ils veulent guider les utilisateurs via le flux de consentement de l’utilisateur ou le flux de consentement administrateur.

• Flux de consentement utilisateur : intervient lorsqu’un développeur d’application dirige les utilisateurs vers le point de terminaison d’autorisation avec l’intention d’enregistrer le consentement pour l’utilisateur actif uniquement.
• Flux de consentement administrateur : intervient lorsqu’un développeur d’application dirige les utilisateurs vers le point de terminaison de consentement administrateur avec l’intention d’enregistrer le consentement pour le locataire dans son intégralité. Pour s’assurer que le flux de consentement administrateur fonctionne correctement, les développeurs d’application doivent répertorier toutes les autorisations dans la propriété RequiredResourceAccess dans le manifeste de l’application. Pour plus d’informations, consultez l’article Manifeste d’application.

Blocs de construction de l’invite de consentement

L’invite de consentement vise à s’assurer que les utilisateurs disposent de suffisamment d’informations pour décider de faire confiance ou non à l’application cliente afin de l’autoriser à accéder aux ressources protégées en leur nom. Comprendre les blocs élémentaires permettent aux utilisateurs invités à donner leur consentement de prendre des décisions en connaissance de cause et aide les développeurs à créer de meilleures expériences utilisateur.

Le diagramme et le tableau suivants fournissent des informations sur les blocs de construction de l’invite de consentement.

#	Composant	Objectif
1	Identificateur de l’utilisateur	Cet identificateur représente l’utilisateur au nom duquel l’application cliente demande à accéder aux ressources protégées.
2	Intitulé	L’intitulé change selon que les utilisateurs suivent le flux de consentement utilisateur ou administrateur. Dans le flux de consentement de l’utilisateur, le titre est « Autorisations demandées », tandis que dans le flux de consentement administrateur, le titre comporte une autre ligne « Accepter pour votre organisation ».
3	Logo de l’application	Cette image donne aux utilisateurs un indice visuel pour déterminer si cette application est bien celle à laquelle ils souhaitaient accéder. Cette image est fournie par les développeurs d’application et la propriété de cette image n’est pas validée.
4	Nom de l’application	Cette valeur indique aux utilisateurs quelle application demande à accéder à leurs données. Ce nom est fourni par les développeurs et la propriété de ce nom d’application n’est pas validée.
5	Nom de l’éditeur et vérification	Le badge bleu « vérifié » signifie que l’éditeur d’application a vérifié son identité à l’aide d’un compte Microsoft Partner Network et a terminé le processus de vérification. Si l’application est vérifiée par l’éditeur, le nom de l’éditeur est indiqué. Si l’application n’est pas vérifiée par l’éditeur, « Non vérifié » apparaît à la place d’un nom d’éditeur. Pour plus d’informations, consultez Vérification par l’éditeur. Lorsque vous sélectionnez le nom de l’éditeur, plus d’informations sur l’application sont affichées. Les informations incluent le nom de l’éditeur, le domaine de l’éditeur, la date de création, les détails de certification et les URL de réponse.
6	Certification Microsoft 365	Le logo de certification Microsoft 365 signifie qu’une application est vérifiée par rapport aux contrôles dérivés des principales infrastructures standard du secteur. Il montre que des pratiques de sécurité et de conformité fortes sont en place pour protéger les données client. Pour plus d’informations, consultez Certification Microsoft 365.
7	Informations sur l’éditeur	Indique si l’application est publiée par Microsoft.
8	Autorisations	Cette liste contient les autorisations demandées par l’application cliente. Les utilisateurs doivent toujours évaluer les types d’autorisations demandées pour comprendre les données que l’application cliente est autorisée à accéder en leur nom. En tant que développeur d’application, nous vous recommandons de demander des autorisations d’accès avec le niveau de privilège minimum.
9	Description de l’autorisation	Cette valeur est fournie par le service exposant les autorisations. Pour afficher les descriptions d’autorisation, vous devez cliquer sur la flèche de développement en regard de l’autorisation.
10	https://myapps.microsoft.com	Ce lien permet aux utilisateurs de passer en revue et de supprimer toutes les applications non-Microsoft qui ont actuellement accès à leurs données.
11	Signalez-le ici	Ce lien est utilisé pour signaler une application suspecte si vous ne faites pas confiance à l’application, si vous pensez qu’elle emprunte l’identité d’une autre application, s’il est susceptible d’utiliser mal vos données ou pour une autre raison.

Scénarios courants et expériences de consentement

La section suivante décrit les scénarios courants et l’expérience de consentement attendue pour chacun d’eux.

L’application exige une autorisation que l’utilisateur a le droit d’accorder

Dans ce scénario de consentement, l’utilisateur accède à une application qui exige un ensemble d’autorisations relevant de l’autorité de l’utilisateur. L’utilisateur est dirigé vers le flux de consentement de l’utilisateur.

Les administrateurs voient un autre contrôle sur l’invite de consentement traditionnelle qui leur permet de donner leur consentement au nom de l’ensemble du locataire. Le contrôle est désactivé par défaut. Par conséquent, le consentement est accordé au nom de l’ensemble du locataire uniquement lorsque les administrateurs cochent explicitement la case. La case à cocher s’affiche uniquement pour au moins le rôle d’administrateur de rôle privilégié . Par conséquent, l’administrateur cloud et l’administrateur d’application ne voient pas cette case.

Les utilisateurs voient l'invite de consentement standard.

L’application exige une autorisation que l’utilisateur n’a pas le droit d’accorder

Dans ce scénario de consentement, l’utilisateur accède à une application qui exige au moins une autorisation qui n’est pas du ressort de l’utilisateur.

Les administrateurs voient un autre contrôle sur l’invite de consentement traditionnelle qui leur permet de donner leur consentement au nom de l’ensemble du locataire.

Les utilisateurs qui ne sont pas administrateurs ne peuvent pas donner leur accord à l'application et doivent demander l'accès à l'application à leur administrateur. Si le workflow du consentement administrateur est activé dans le client de l'utilisateur, les utilisateurs peuvent envoyer une demande d'approbation de l'administrateur depuis l'invite de consentement. Pour plus d’informations sur le workflow du consentement administrateur, consultez Workflow du consentement administrateur.

L’utilisateur est dirigé vers le flux de consentement de l’administrateur

Dans ce scénario de consentement, l’utilisateur navigue ou est dirigé vers le flux de consentement administrateur.

Les utilisateurs administrateurs voient l'invite de consentement administrateur. Le titre et les descriptions des autorisations ont changé sur cette invite, les modifications mettent en évidence le fait que l’acceptation de cette invite accorde à l’application l’accès aux données demandées pour le compte de l’ensemble du locataire.

Les utilisateurs ne peuvent pas donner leur consentement à l'application et doivent demander l'accès à l'application à leur administrateur.

Le consentement administrateur via le centre d’administration Microsoft Entra

Dans ce scénario, un administrateur consent toutes les autorisations qu’une application demande, ce qui peut inclure des autorisations déléguées pour le compte de tous les utilisateurs du locataire. L’administrateur octroie un consentement via la page Autorisations d’API de l’inscription d’application dans le centre d’administration Microsoft Entra.

Tous les utilisateurs de ce locataire ne voient pas la boîte de dialogue de consentement, sauf si l’application requiert de nouvelles autorisations. Pour connaître les rôles administrateur habilités à donner leur consentement pour les autorisations déléguées, consultez Autorisations du rôle administrateur dans Microsoft Entra ID.

Important

Pour les applications monopages (SPA) qui utilisent MSAL.js, vous devez actuellement accorder un consentement explicite à l’aide du bouton Accorder des autorisations. Sinon, l’application échoue lorsque le jeton d’accès est demandé.

Problèmes courants

Cette section décrit les problèmes courants liés à l’expérience de consentement et les conseils de dépannage possibles.

• Erreur 403

  • Le cas est-il un scénario délégué? De quelles autorisations un utilisateur dispose-t-il ?
  • Les autorisations nécessaires sont-elles ajoutées pour utiliser le point de terminaison ?
  • Vérifiez le jeton pour voir s’il a les revendications nécessaires pour appeler le point de terminaison.
  • Quelles autorisations sont accordées ? Qui l’a accordé ?

• L’utilisateur ne peut pas donner son consentement

  • Vérifiez si l’administrateur client a désactivé le consentement de l’utilisateur pour votre organisation
  • Vérifiez si les autorisations que vous demandez sont des autorisations limitées par l’administrateur.

• L’utilisateur est toujours bloqué même après le consentement de l’administrateur

  • Vérifiez si des autorisations statiques sont configurées pour être un sur-ensemble d’autorisations demandées dynamiquement.
  • Vérifiez si l’attribution d’un utilisateur est requise pour l’application.

Résoudre les erreurs connues

Pour connaître les étapes de résolution des problèmes, consultez Erreur inattendue lors de l’exécution du consentement sur une application.

Contenu connexe

• Obtenez une présentation détaillée de la façon dont l’infrastructure de consentement Microsoft Entra implémente le consentement.
• Pour plus de détails, découvrez comment une application multilocataire peut utiliser l’infrastructure de consentement pour implémenter le consentement « utilisateur » et « administrateur », prenant en charge des modèles d’application multiniveau plus avancés.
• Découvrez comment configurer le domaine de l’éditeur de l’application.