Acquisition d’une autorisation d’accès aux ressources

  • Article

Cet article vous aidera, en tant que développeur, à comprendre comment mieux garantir Confiance Zéro lors de l’acquisition d’autorisations d’accès aux ressources pour votre application. Pour accéder à une ressource protégée comme les emails ou des données de calendrier, votre application a besoin de l’autorisation du propriétaire de la ressource. Le propriétaire de la ressource peut consentir à ou refuser la demande de votre application. Votre application reçoit un jeton d’accès lorsque le propriétaire de la ressource accorde son consentement ; votre application ne recevra pas de jeton d’accès lorsque le propriétaire de la ressource refuse l’accès.

Examen conceptuel

Vous pouvez utiliser le Plateforme d'identités Microsoft pour authentifier et autoriser vos applications et gérer les autorisations et le consentement. Commençons par quelques concepts :

  • L’authentification (parfois raccourcie à AuthN) est le processus de prouver que votre identité revendiquée est exacte. La Plateforme d’identités Microsoft utilise le protocole OpenID Connect pour gérer l’authentification. L’autorisation (parfois raccourcie à AuthZ) accorde à une partie authentifiée l’autorisation d’effectuer quelque chose. Elle spécifie les données que la partie authentifiée peut accéder. La Plateforme d’identités Microsoft utilise le protocole OAuth 2.0 pour gérer l’autorisation. Les options d’autorisation incluent les listes de contrôle d’accès (ACL), le contrôle d’accès en fonction du rôle et le contrôle d’accès aux attributs (ABAC). L’authentification est souvent un facteur d’autorisation.

  • Pour accéder aux données, votre application peut utiliser l'accès délégué (agir au nom d'un utilisateur connecté) ou l'accès direct (agir uniquement en tant qu'identité propre de l'application). L’accès délégué nécessite des permissions déléguées (également appelées étendues) ; le client et l’utilisateur doivent être autorisés séparément à effectuer la demande. L’accès direct peut nécessiter des autorisations d’application (également appelées rôles d’application) ; lorsque des rôles d’application sont accordés aux applications, ils peuvent être appelés autorisations d’applications.

  • Les permissions déléguées, utilisées avec un accès délégué, permettent à une application d’agir au nom d’un utilisateur, en accédant uniquement à ce que l’utilisateur peut accéder. L’autorisation d’application, utilisée avec un accès direct, permet à une application d’accéder à toutes les données auxquelles l’autorisation est associée. Seul un administrateur ou un propriétaire du principal de service peut donner son consentement aux autorisations d’application.

  • Les applications reçoivent des autorisations par le biais du consentement ; les utilisateurs ou les administrateurs autorisent une application à accéder à une ressource protégée. Une invite de consentement répertorie les autorisations requises par l’application, ainsi que les informations de l’éditeur.

  • Les propriétaires d'applications de ressources peuvent préautoriser les applications clientes (dans le portail Azure ou en utilisant PowerShell et des API comme Microsoft Graph). Ils peuvent accorder des autorisations sur les ressources sans exiger des utilisateurs qu'ils voient une demande de consentement pour l'ensemble des autorisations qui ont été préautorisées.

Différences entre les autorisations déléguées et autorisation d’application

Les applications fonctionnent en deux modes : lorsqu’un utilisateur est présent (permission déléguée) et lorsqu’il n’y a pas d’utilisateur (autorisation d’application). Lorsqu’il y a un utilisateur devant une application, vous êtes obligé d’agir au nom de cet utilisateur ; vous ne devez pas agir pour le compte de l’application elle-même. Lorsqu’un utilisateur dirige votre application, vous agissez en tant que délégué pour cet utilisateur. Vous obtenez l’autorisation d’agir pour le compte de l’utilisateur que le jeton identifie.

Les applications de type de service (tâches en arrière-plan, démons, processus serveur à serveur) n’ont pas d’utilisateurs qui peuvent s’identifier eux-mêmes ou taper un mot de passe. Ils nécessitent une autorisation d’application pour agir pour le compte de lui-même (pour le compte de l’application de service).

bonnes pratiques d’autorisation d’application Confiance Zéro

Votre approche d’autorisation aura l’authentification en tant que composant lorsque vous vous connectez à un utilisateur présent à l’application et à la ressource que vous appelez. Lorsque votre application agit pour le compte d’un utilisateur, nous ne faisons pas confiance à une application appelante pour nous indiquer qui est l’utilisateur ou laisser l’application décider qui est l’utilisateur. Microsoft Entra ID vérifie et fournit directement des informations sur l’utilisateur dans le jeton.

Lorsque vous devez autoriser votre application à appeler une API ou à autoriser votre application afin que l’application puisse accéder à une ressource, les schémas d’autorisation modernes peuvent nécessiter une autorisation via une autorisation et une infrastructure de consentement. Référencez les meilleures pratiques de sécurité pour les propriétés d’application qui incluent l’URI de redirection, les jetons d’accès (utilisés pour les flux implicites), les certificats et les secrets, l’URI d’ID d’application et la propriété de l’application.

Étapes suivantes