Introduction

Dans le monde de Microsoft 365 et d’Entra ID, une phrase revient régulièrement dans les discussions sécurité : « Il faut supprimer l’application XXX, elle permet à tous les utilisateurs de lire toutes les données de tous les utilisateurs ! ». Cette affirmation, bien que compréhensible dans un contexte de sécurisation, révèle souvent une méconnaissance des mécanismes réels d’autorisation dans l’écosystème Microsoft.

L’objet de cet article est de clarifier une notion fondamentale mais parfois nébuleuse : la différence entre les permissions déléguées et les permissions d’application dans Microsoft Entra ID pour les applications utilisant OAuth 2.0.

Les deux types de permissions dans Entra ID

Microsoft Entra ID distingue deux catégories de permissions pour les applications tierces :

1. Les permissions déléguées (Delegated Permissions)

Les permissions déléguées permettent à une application d’agir au nom d’un utilisateur connecté. Dans ce modèle :

• L’application n’a accès aux ressources que lorsqu’un utilisateur est authentifié
• Les actions sont effectuées dans le contexte de cet utilisateur spécifique
• L’application hérite des limitations de l’utilisateur connecté

2. Les permissions d’application (Application Permissions)

Les permissions d’application, aussi appelées permissions « app-only », accordent à une application un accès autonome aux ressources. Caractéristiques :

• L’application peut accéder aux ressources sans qu’aucun utilisateur ne soit connecté
• Principalement utilisées pour les services d’arrière-plan, les tâches automatisées
• L’application dispose de tous les droits qui lui sont explicitement accordés

Le processus de consentement OAuth 2.0

Qu’est-ce que le consentement ?

Lorsqu’une application utilise OAuth 2.0 pour accéder aux ressources Microsoft, un processus de consentement peut être déclenché. Cette étape cruciale détermine quelles permissions l’application obtiendra.

Consentement pour les permissions déléguées

Pour les permissions déléguées, le consentement peut être donné par :

• L’utilisateur lui-même : pour les permissions classifiées comme « basse » ou « moyenne » selon la classification Microsoft
• Un administrateur : pour toutes les permissions, notamment celles classifiées comme « élevées »

La configuration du tenant détermine qui peut consentir à quoi, offrant un contrôle granulaire aux administrateurs.

Consentement pour les permissions d’application

Les permissions d’application nécessitent exclusivement un consentement administrateur. Cette restriction s’explique par la nature autonome de ces permissions qui permettent un accès direct aux ressources, sans intervention utilisateur.

L’intersection : le concept clé des permissions déléguées

Le principe fondamental

Voici le point crucial souvent mal compris : avec les permissions déléguées, l’accès réel aux données correspond à l’intersection entre :

1. Les droits de l’utilisateur connecté dans le tenant
2. Les permissions accordées à l’application

Exemple pratique

Considérons une application qui dispose de la permission déléguée User.ReadWrite.All :

Scénario 1 : Utilisateur standard sans droits d’administration

• L’utilisateur ne peut modifier que son propre profil
• L’application ne pourra donc modifier que le profil de cet utilisateur spécifique
• Résultat : Aucun accès privilégié accordé

Scénario 2 : Administrateur global connecté

• L’administrateur peut modifier tous les profils utilisateur
• L’application hérite de cette capacité
• Résultat : L’application peut modifier tous les profils

Comparaison avec les permissions d’application

Avec les permissions d’application, l’application dispose de tous les droits qui lui sont accordés, indépendamment de tout utilisateur connecté. Une application avec User.ReadWrite.All en permission d’application peut modifier tous les profils utilisateur du tenant.

Différences pratiques et cas d’usage

Permissions déléguées – Cas d’usage typiques

• Applications interactives : Applications web, mobiles où l’utilisateur se connecte
• Outils de productivité : Clients de messagerie, applications de calendrier
• Applications SaaS : Outils collaboratifs où chaque utilisateur accède à ses propres données

Permissions d’application – Cas d’usage typiques

• Services de sauvegarde : Applications qui doivent sauvegarder toutes les données du tenant
• Outils d’automatisation : Scripts PowerShell, tâches planifiées
• Solutions de monitoring : Surveillance de l’activité globale du tenant
• Intégrations systèmes : Synchronisation de données entre systèmes

Applications Microsoft par défaut

Une particularité importante concerne les applications Microsoft natives comme :

• Microsoft Exchange Online
• SharePoint Online
• Microsoft Teams
• OneDrive for Business

Ces applications utilisent OAuth 2.0 et bénéficient d’un consentement pré-validé par Microsoft. C’est pourquoi vous ne voyez pas de fenêtre de consentement lors de leur première utilisation : le consentement est implicite et fait partie de votre licence Microsoft 365.

Bonnes pratiques de sécurité

Pour les administrateurs

1. Auditez régulièrement les permissions accordées aux applications
2. Privilégiez les permissions déléguées quand c’est possible
3. Configurez les classifications de permissions selon vos besoins organisationnels
4. Formez les utilisateurs au processus de consentement
5. Utilisez les outils de gouvernance comme Azure AD Access Reviews

Pour les développeurs

1. Demandez le minimum de permissions nécessaires (principe du moindre privilège)
2. Préférez les permissions déléguées pour les applications interactives
3. Documentez clairement l’usage de chaque permission demandée
4. Implémentez des contrôles supplémentaires dans votre code

Implications pour la sécurité organisationnelle

Réévaluation des risques

La compréhension de ces mécanismes change fondamentalement l’évaluation des risques :

• Une application avec des permissions déléguées étendues n’est dangereuse que si des utilisateurs privilégiés l’utilisent
• Les véritables risques proviennent souvent des permissions d’application accordées sans discernement

Stratégie de gouvernance

Cette connaissance permet de mettre en place une stratégie de gouvernance plus fine :

• Contrôle strict des permissions d’application
• Formation des utilisateurs sur le consentement
• Surveillance des applications utilisées par les comptes privilégiés

Pour finir

La distinction entre permissions déléguées et permissions d’application est fondamentale pour comprendre les mécanismes d’autorisation dans l’écosystème Microsoft 365. Cette compréhension permet :

1. Une évaluation plus précise des risques liés aux applications tierces
2. Une stratégie de sécurité plus nuancée et efficace
3. Une prise de décision éclairée concernant l’approbation des applications

La prochaine fois que vous entendrez parler d’une application « dangereuse », pensez à vérifier le type de permissions utilisé et le contexte d’utilisation avant de tirer des conclusions hâtives.

L’objectif n’est pas de minimiser les risques de sécurité, mais de les évaluer correctement pour prendre les bonnes décisions de gouvernance et de protection de vos environnements Microsoft 365.

---

Sources et références

• Microsoft Learn – Permissions and consent in the Microsoft identity platform
• Microsoft Security – Zero Trust developer strategy for delegated permissions
• Microsoft Learn – Configure permission classifications
• Microsoft Learn – Microsoft Graph permissions reference
• Cahier de vacances Microsoft 365 – Jour 9, Bastien Perez, Été 2024