Expérience de consentement pour les applications dans Azure Active Directory

Dans cet article, vous allez découvrir l’expérience utilisateur de consentement pour les applications dans Azure Active Directory (Azure AD). Vous pourrez alors gérer intelligemment des applications pour votre organisation et/ou développer des applications avec une expérience de consentement plus fluide.

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 locataire 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é RequiredResourceAccess dans le manifeste de l’application. Pour plus d’informations, consultez l’article Manifeste d’application.

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 de construction permet aux utilisateurs invités à donner leur consentement de prendre des décisions plus avisées 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.

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 utilisateur, l’intitulé sera « Permissions requested » (Autorisations demandées), tandis que dans le flux de consentement administrateur, l’intitulé aura 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.

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 verront 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 locataire. 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. Cette 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.

Invite de consentement pour le scénario 1a

Les utilisateurs voient l’invite de consentement standard.

Capture d'écran représentant 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 locataire.

Invite de consentement pour le scénario 1a

Les utilisateurs non-administrateurs ne peuvent pas donner leur consentement à l’application et sont invités à contacter leur administrateur pour autoriser l’accès à l’application. Si le workflow du consentement administrateur est activé dans le locataire de l’utilisateur, les utilisateurs non-administrateurs 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.

Capture d'écran de l'invite de consentement demandant à l'utilisateur de contacter un administrateur pour accéder à l'application.

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.

Invite de consentement pour le scénario 3a

Les utilisateurs non-administrateurs ne peuvent pas donner leur consentement à l’application et sont invités à contacter leur administrateur pour autoriser l’accès à l’application.

Capture d'écran de l'invite de consentement demandant à l'utilisateur de contacter un administrateur pour accéder à l'application.

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 accorde le consentement via la page Autorisations d’API de l’inscription d’application dans le portail Azure.

Capture d’écran du consentement administrateur explicite via le portail Azure.

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 Azure AD.

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.

Étapes suivantes