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 aux ressources protégées telles que les e-mails ou les données de calendrier, votre application a besoin de l’autorisation du propriétaire de la ressource. Le propriétaire de la ressource peut donner son consentement 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 reçoit pas de jeton d’accès lorsque le propriétaire de la ressource refuse l’accès.

Examen conceptuel

Vous pouvez utiliser la 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 OAuth2.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é (agissant au nom d’un utilisateur connecté) ou l’accès direct (agissant uniquement en tant qu’identité de l’application) permet à votre application d’accéder aux données. L’accès délégué nécessite des autorisations 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 les applications reçoivent des rôles d’application, elles peuvent être appelées autorisations d’applications.

• Les autorisations 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 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é-authentification 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 avec PowerShell et les API comme Microsoft Graph. Ils peuvent accorder des autorisations de ressource sans demander aux utilisateurs d’afficher une invite de consentement pour l’ensemble des autorisations pré-autorisées .

Différence entre l’autorisation déléguée et l’autorisation d’application

Les applications fonctionnent en deux modes : lorsqu’un utilisateur est présent (autorisation 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 son propre compte (pour le compte de l'application de service).

Bonnes pratiques d’autorisation des applications Confiance Zéro

Votre approche d’autorisation a 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.

Prochaines étapes

• 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.
• Développer une stratégie d’autorisations déléguées vous aide à implémenter la meilleure approche pour gérer les autorisations dans votre application et à développer avec des principes de confiance Zéro.
• Développer une stratégie d’autorisations d’application vous aide à décider de l’approche des autorisations d’application pour la gestion des informations d’identification.
• Fournissez des informations d’identification d’identité d’application lorsqu’il n’y a pas d’utilisateur explique pourquoi les Identités Gérées pour les ressources Azure représentent la meilleure pratique pour l’utilisation des informations d’identification client dans les services (applications sans 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.
• Dans votre cycle de vie de développement d’applications, utilisez les meilleures pratiques de développement de gestion des identités et des accès de Confiance Zéro pour créer des applications sécurisées.
• La création d’applications avec une approche Confiance Zéro pour l’identité continue à partir de l’article sur les meilleures pratiques de développement d’identité et de gestion des accès Zero Trust pour vous aider à utiliser une approche Confiance Zéro pour l’identité dans votre cycle de vie de développement logiciel (SDLC).