Exemple d’API protégée par l’infrastructure de consentement d’identité Microsoft

Cet article peut vous aider, en tant que développeur, à concevoir votre stratégie d’autorisations d’application pour fournir des privilèges minimum. Avant de continuer, consultez l’article de protection des API pour découvrir les meilleures pratiques en matière d’inscription, d’autorisations et d’accès.

Examinons comment une API protégée par la plateforme d’identités Microsoft utilise l’infrastructure de consentement d’identité Microsoft. Nous utilisons l’API Microsoft Graph comme exemple, car elle fait l’utilisation la plus étendue de l’infrastructure de consentement de la plateforme d’identités Microsoft.

Convention d’affectation de noms pour les noms d’autorisations

L’équipe Microsoft Graph a créé une convention d’affectation de noms pour permettre aux noms d’autorisations de connecter plus facilement l’autorisation à l’accès aux ressources que l’autorisation active. Les noms d’autorisations Microsoft Graph adhèrent à un modèle resource.operation.constraint simple. Les deux opérations principales sont Read et ReadWrite (qui inclut la mise à jour et la suppression).

L’élément de contrainte affecte le degré d’accès que votre application possède dans le répertoire. Microsoft Graph prend en charge ces contraintes :

• Toute accorde l’autorisation à votre application d’effectuer les opérations sur toutes les ressources du type spécifié dans un répertoire.
• Le partage accorde l’autorisation à votre application d’effectuer les opérations sur les ressources partagées par d’autres utilisateurs avec l’utilisateur connecté.
• AppFolder accorde l’autorisation à votre application de lire et d’écrire des fichiers dans un dossier dédié dans OneDrive. Cette contrainte est exposée uniquement sur l’objet d’autorisations Files et n’est valide que pour les comptes Microsoft.
• Si vous spécifiez Aucune contrainte, votre application ne peut effectuer que les opérations sur les ressources que l’utilisateur connecté possède.

Accès et opérations sur des ressources spécifiques

Examinons certaines autorisations ou étendues pour l’objet utilisateur dans Microsoft Graph pour voir comment les concepteurs d’API Microsoft ont activé un accès et des opérations spécifiques sur des ressources spécifiques :

User.Read et User.ReadWrite existent (par opposition à une autorisation unique comme User.Access celle qui n’existe pas) afin que les applications puissent suivre le principe de confiance zéro des privilèges minimum. Si le développeur n’a pas d’exigence et de code pour mettre à jour le profil de l’utilisateur, l’application ne demande User.ReadWritepas . Par conséquent, un acteur incorrect ne peut pas compromettre l’application et l’utiliser pour modifier les données.

Notez que User.Read cela ne permet pas simplement à l’application d’accéder à l’objet utilisateur. Chaque autorisation représente une plage d’opérations spécifique. Il est important que les développeurs et les administrateurs lisent la description de l’autorisation pour voir exactement ce qu’une autorisation spécifique active. User.Read, en plus d’activer la lecture du profil complet de l’utilisateur actuel, permet à l’application de voir les informations de base de l’objet Organizations dans Microsoft Graph.

Examinons une autre autorisation :

Plage d’opérations que User.ReadBasic.All commence avec tout ce que User.Read fait. En outre, vous pouvez accéder au nom d’affichage, au prénom et au nom de famille, à l’adresse e-mail, à la photo et à l’ouverture d’extensions pour d’autres utilisateurs de l’organisation. La plage d’opérations spécifique permet aux applications d’avoir une interface utilisateur de sélecteur de personnes agréable et est un exemple de concepteurs d’API utilisant une autorisation pour activer une plage d’opérations spécifique.

Examinons quelques autorisations supplémentaires sur l’objet utilisateur Microsoft Graph :

Comme avec User.Read et User.ReadWrite, User.Read.All et User.ReadWrite.All sont des autorisations distinctes qui permettent à une application de suivre le principe de confiance zéro de privilège minimum.

User.Read.All est intéressant, car chaque utilisateur de l’organisation a cette fonctionnalité (par exemple, ouvrir Outlook, monter et descendre dans une chaîne de création de rapports). Vous pouvez, en tant qu’individu, voir le profil utilisateur complet de tous les autres utilisateurs de votre organisation. Toutefois, les concepteurs d’API Microsoft Graph ont décidé que seuls les administrateurs doivent autoriser une application à effectuer la même opération, car User.Read.All inclut la hiérarchie organisationnelle du locataire. Si une personne malveillante accédait à ces informations, elle pourrait monter une attaque ciblée de hameçonnage où l’e-mail de hameçonnage proviendrait du manager d’une personne ou de son supérieur hiérarchique.

User.ReadWrite.All est une plage puissante de fonctionnement. Une application disposant de cette autorisation peut mettre à jour ou même supprimer chaque utilisateur du locataire. En tant qu’autorisation déléguée, lorsqu’un utilisateur est devant l’application, l’application ne peut faire que ce que l’utilisateur actuel peut faire. Les utilisateurs réguliers ne peuvent pas mettre à jour ou supprimer d’autres utilisateurs, quelles que soient les autorisations de l’application. Toutefois, lorsqu’un administrateur client utilise l’application, il peut effectuer ces opérations. Lorsque vous décidez d’accorder ou de refuser cette autorisation, évaluez votre application en gardant à l'esprit un utilisateur administrateur d’un client.

Autorisations nécessitant le consentement de l’administrateur

Étant donné la puissance de User.Read.All et de User.ReadWrite.All, les concepteurs de l'API Microsoft Graph ont désigné ces autorisations comme nécessitant le consentement de l'administrateur. Ajoutons une colonne Administrateur à notre table d’autorisations pour indiquer quand l’autorisation requiert le consentement de l’administrateur :

Comme illustré dans l’article Demander des autorisations qui nécessitent un consentement administratif , les administrateurs de locataires peuvent dépasser les exigences et désigner toutes les autorisations d’application dans leur locataire comme nécessitant le consentement de l’administrateur. Concevez votre application pour gérer gracieusement le cas où vous ne recevez pas de jeton de votre requête. L’absence de consentement est l’une des nombreuses raisons pour lesquelles votre application risque de ne pas recevoir de jeton.

Étapes suivantes

• Appeler une API à partir d’une autre API vous aide à garantir la Confiance Zéro lorsqu’une de vos API doit en appeler une autre, et à développer en toute sécurité votre application lorsqu’elle fonctionne au nom d’un utilisateur.
• Acquérir l’autorisation d’accéder aux ressources vous aide à comprendre comment garantir la confiance zéro lors de l’acquisition des autorisations d’accès aux ressources pour votre application.
• Personnaliser les jetons décrit les informations que vous pouvez recevoir dans les jetons Microsoft Entra. Il explique comment personnaliser des jetons afin d’améliorer la flexibilité et le contrôle tout en augmentant la sécurité confiance zéro de l’application avec des privilèges minimum.
• Configurer les revendications de groupe et les rôles d’application dans les jetons vous montre comment configurer des définitions de rôle d’application pour vos applications et comment affecter des groupes de sécurité aux rôles d’application. Ces méthodes permettent d’améliorer la flexibilité et le contrôle tout en augmentant la sécurité confiance zéro de l’application avec des privilèges minimum.
• Demander des autorisations qui nécessitent un consentement administratif décrit l’autorisation et l’expérience de consentement lorsque les autorisations d’application nécessitent un consentement administratif.
• Dans ce guide de démarrage rapide : Protéger une API web avec la plateforme d’identités Microsoft, télécharger et exécuter un exemple de code qui montre comment protéger une API web ASP.NET.
• Dans ce tutoriel : Transformez et protégez votre API dans Gestion des API Azure, découvrez comment configurer des stratégies courantes pour masquer les informations de pile technologique et les URL d’origine dans le corps de la réponse HTTP de l’API.
• Les meilleures pratiques d’autorisation vous aident à implémenter les modèles d’autorisation, d’autorisation et de consentement les mieux adaptés à vos applications.