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 décider des types d’autorisations qui sont demandés et s’ils souhaitent guider les utilisateurs vers le flux de consentement utilisateur ou vers 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é
RequiredResourceAccessdans 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, l'intitulé est « Permissions requested » (Autorisations demandées), tandis que dans le flux de consentement administrateur, l'intitulé a une ligne supplémentaire « Accept for your organization » (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 de l’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. La sélection du nom de l’éditeur affiche plus d’informations sur l’application, telles que 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 Certification Microsoft 365 signifie qu’une application a été vérifiée par rapport aux contrôles dérivés des principaux frameworks standard de l’industrie, et que de solides pratiques de sécurité et de conformité sont en place pour protéger les données des clients. 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 systématiquement évaluer les types d’autorisations demandées pour savoir à quelles données l’application cliente aura accès en leur nom s’ils donnent leur consentement. 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 |
Il s’agit du lien via lequel les utilisateurs peuvent afficher et supprimer 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 n’avez pas confiance en elle, si vous pensez qu’elle se fait passer pour une autre application, si vous pensez qu’elle va utiliser vos données à mauvais escient ou pour toute 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 une option de contrôle supplémentaire dans l'invite de consentement standard qui leur permet de donner un consentement pour l'intégralité du client. Cette option est désactivée par défaut. Ainsi, le consentement sera accordé au nom du locataire dans son ensemble uniquement si l'administrateur coche la case correspondante. La case à cocher s’affiche uniquement pour le rôle Administrateur général et pas pour les rôles Administrateur du cloud et Administrateur d’application.
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 bénéficient d'une option de contrôle supplémentaire par rapport à l'invite de consentement standard qui leur permet de donner un accord pour l'intégralité du client.
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. L’intitulé et les descriptions d’autorisation ont été modifiés sur cette invite. Les modifications indiquent qu’en acceptant cette invite, l’utilisateur autorise l’application à accéder 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.
Aucun utilisateur de ce locataire ne verra la boîte de dialogue de consentement, sauf si l’application exige 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
- S’agit-il d’un scénario d’autorisation déléguée ? 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.
- Pour quelles autorisations un consentement a-t-il été accordé ? Qui l’a accordé ?
L’utilisateur ne peut pas donner son consentement
- Vérifiez si l’administrateur du locataire a désactivé le consentement 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 quand l’administrateur a donné son consentement.
- 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.
Voir aussi
- 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 la façon dont une application mutualisée peut utiliser l’infrastructure de consentement pour implémenter un consentement de type « utilisateur » et « admin », en prenant en charge des modèles d’applications mutualisées plus avancés.
- Découvrez comment configurer le domaine de l’éditeur de l’application.