Acquérir l’autorisation d’accéder aux ressources
Cet article vous aide, en tant que développeur, à comprendre comment garantir la 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 donne son consentement. En revanche, l’application ne reçoit pas de jeton d’accès si 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.
L’accès délégué (agir au nom d’un utilisateur connecté) ou l’accès direct (agir uniquement avec l’identité propre de l’application) permet à votre application d’accéder aux données. 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 à des applications, ils peuvent être appelés « autorisations d’application ».
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.
Le consentement est la façon dont les applications reçoivent des autorisations. 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.
La pré-autorisation est la façon dont les propriétaires d’applications de ressources accordent l’accès aux applications clientes. Ils peuvent le faire dans le Portail Azure ou en utilisant PowerShell et des API comme Microsoft Graph. Ils peuvent accorder des autorisations sur les ressources sans obliger les utilisateurs à répondre à une invite de consentement pour l’ensemble des autorisations 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 inclut un composant d’authentification lorsque 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
- Personnaliser les jetons décrit les informations que vous pouvez recevoir dans les jetons Microsoft Entra. Vous découvrirez comment personnaliser des jetons pour 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 vos applications avec des définitions de rôle d’application 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.
- Développer une stratégie de permissions déléguées vous aide à implémenter la meilleure approche pour gérer les autorisations dans votre application et à développer du code selon les principes de la Confiance Zéro.
- Développer une stratégie d’autorisations d’application vous aide à choisir une approche en matière d’autorisations d’application pour la gestion des informations d’identification.
- Fournir des informations d’identification d’identité d’application en l’absence d’utilisateur explique pourquoi les identités managées pour les ressources Azure constituent la meilleure pratique en matière d’informations d’identification client pour les services (applications non-utilisateur) sur Azure.
- 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.
- Utilisez les meilleures pratiques de développement de la gestion des identités et des accès Confiance Zéro dans votre cycle de développement d'applications pour créer des applications sécurisées.
- La création d’applications avec une approche Confiance Zéro de l’identité continue à partir de l’article sur les bonnes pratiques de développement d’identité et de gestion des accès Confiance Zéro pour vous aider à utiliser une approche Confiance Zéro de l’identité dans votre cycle de vie de développement logiciel (SDLC).