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 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 le Plateforme d’identités Microsoft utilise l’infrastructure de consentement de l’identité Microsoft. Nous utilisons l’API Microsoft Graph comme exemple, car elle utilise au mieux 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 Lecture 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 l’annuaire. Microsoft Graph prend en charge ces contraintes :

• Toutes accordent l’autorisation à votre application d’effectuer les opérations sur toutes les ressources du type spécifié dans un répertoire.
• Partagé 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 n'est exposée que sur l'objet autorisations de Fichiers et n'est valable 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 qui n’existe pas) afin que les applications puissent suivre le principe de Confiance Zéro de privilège minimum. Si le développeur n’a pas de conditions requises et de code pour mettre à jour le profil de l’utilisateur, l’application ne demande pas de User.ReadWrite. Par conséquent, un attaquant 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 qui User.ReadBasic.All commence par tout ce qui User.Read se passe. En outre, vous pouvez accéder au nom d’affichage, au prénom, au nom de famille, à l’adresse e-mail et à la photo, et ouvrir les 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 privilège minimum Confiance Zéro.

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 client. Si un mauvais acteur a accédé à ces informations, il peut monter une attaque de hameçonnage ciblée où l’email de hameçonnage provient du responsable d’une personne ou du responsable de son responsable.

User.ReadWrite.All est une gamme puissante d’opérations. Une application disposant de cette autorisation peut mettre à jour ou même supprimer chaque utilisateur du client. En tant que permission 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, vous devez évaluer votre application avec un utilisateur administrateur client à l’esprit.

Autorisations nécessitant le consentement administrateur

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

Comme illustré dans l’article Demander des autorisations qui nécessitent un consentement administratif, les administrateurs de locataires peuvent remplacer les exigences et désigner toutes les autorisations d’application dans leur locataire comme nécessitant le consentement de l’administrateur. Vous êtes sage de concevoir votre application pour gérer correctement quand vous ne recevez pas de jeton de votre demande. 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 d’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. Cela explique comment personnaliser des jetons pour améliorer la flexibilité et le contrôle tout en augmentant la sécurité de Confiance Zéro de l’application avec des privilèges minimums.
• 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é de Confiance Zéro de l’application avec des privilèges minimums.
• Demander des autorisations qui nécessitent un consentement administratif décrit l’expérience d’autorisation et 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 Azure API Management, 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.