Comment auditer les applications OAuth tierces sur Slack, GitHub et Microsoft 365

Pour auditer les applications OAuth tierces, il faut vérifier séparément la liste d'autorisation propre à chaque plateforme : la page Installed Apps de Slack, la politique d'applications OAuth de l'organisation GitHub, et la liste des applications d'entreprise de Microsoft Entra. Chacune montre une tranche différente du même problème sous-jacent — quelles applications peuvent agir sur vos données — et aucune ne montre les deux autres.

Ce guide donne le chemin exact pour chaque plateforme, ce qu'il montre, et où un audit plateforme par plateforme atteint ses limites.

Où voir les applications OAuth autorisées dans Slack ?

Rendez-vous dans Settings & administration → Manage apps, ce qui ouvre le Slack Marketplace limité à votre espace de travail, puis sélectionnez Installed Apps en haut de la barre latérale. Cette fonction est disponible sur tous les plans Slack et liste chaque application installée avec les scopes pour lesquels elle a été approuvée.

Sur Enterprise Grid, la section Integrations du tableau de bord d'administration ajoute une vue à l'échelle de l'organisation couvrant tous les espaces de travail à la fois. Cette vue inter-espaces de travail repose sur le scope admin.apps:read, réservé à Enterprise Grid et qui — même dans ce cas — indique seulement quelles applications sont approuvées, restreintes ou en attente ; il ne révèle pas la liste complète des scopes de chaque application dans ce même appel. Sur un espace de travail unique, la page Installed Apps reste la source de vérité pour savoir ce qu'une application peut réellement faire.

Où voir les applications OAuth autorisées dans GitHub ?

Rendez-vous dans Settings → Third-party Access → OAuth app policy de votre organisation. Les nouvelles organisations ont les restrictions d'accès aux applications OAuth activées par défaut, donc cette page est aussi celle où les membres demandent l'accès à une nouvelle application et où un propriétaire l'approuve ou la refuse. Pour révoquer une application précédemment approuvée, retrouvez-la dans la même liste et sélectionnez Deny access.

Les GitHub Apps (un mécanisme distinct des OAuth Apps classiques, utilisé par la plupart des intégrations modernes) se consultent ailleurs : Settings → Integrations → GitHub Apps (ou Installed GitHub Apps) de l'organisation liste ce qui est installé et à quels dépôts chacune peut accéder.

Depuis 2026, une organisation peut aussi définir des contrôles graduels sur qui est même autorisé à *demander* une nouvelle application en premier lieu, depuis Settings → Third-party Access : les membres et les collaborateurs externes peuvent tous deux demander des applications (le comportement par défaut de longue date), les collaborateurs externes peuvent être bloqués tandis que les membres conservent cette possibilité, ou les deux groupes peuvent se voir empêcher de demander la moindre application — ce qui réduit le périmètre de l'audit avant même qu'une demande n'atteigne la file d'attente d'un propriétaire. La restriction d'accès aux applications OAuth à l'échelle de l'organisation peut elle-même être entièrement désactivée, ce qui supprime l'étape d'approbation pour tous les membres — un paramètre qu'il vaut la peine de vérifier avant de considérer la liste de politique d'applications OAuth comme un registre complet de ce qui a été autorisé.

Où voir les applications OAuth autorisées dans Microsoft 365 ?

Connectez-vous au Microsoft Entra admin center et allez dans Identity → Applications → Enterprise applications → All applications. Sélectionnez une application, puis Permissions. L'onglet Admin consent affiche les autorisations accordées pour l'ensemble du tenant — et peut être révoqué directement à cet endroit. L'onglet User consent montre ce que chaque utilisateur a approuvé individuellement pour lui-même — et le portail ne propose pas de bouton de révocation à cet effet ; pour revenir en arrière, il faut passer par un appel à l'API Microsoft Graph ou une commande PowerShell exécutée par une personne disposant du rôle Cloud Application Administrator. Si un tenant bloque purement et simplement le consentement utilisateur, un administrateur global peut activer à la place un flux de consentement administrateur, de sorte qu'une demande bloquée devienne une demande examinable plutôt qu'une impasse — voir le guide d'accès Microsoft 365 pour le détail du fonctionnement de cette file d'examen.

Pourquoi un audit plateforme par plateforme est-il difficile à maintenir à jour ?

Trois consoles, trois formats, trois rôles d'administrateur différents rien que pour y accéder. La vue programmatique à l'échelle de l'organisation de Slack nécessite Enterprise Grid ; les autorisations accordées au niveau utilisateur de Microsoft nécessitent PowerShell ou Graph, pas un clic dans le portail ; GitHub sépare les OAuth Apps classiques des GitHub Apps en deux listes distinctes qu'un administrateur doit savoir consulter séparément. Slack scinde en outre sa propre vue Installed Apps en onglets Approved, Restricted et Requests, si bien qu'un passage complet suppose de vérifier trois filtres en plus des trois plateformes. Aucune des trois ne classe une application par niveau de risque, et aucune ne vous dit si le même fournisseur est également connecté sur les deux autres plateformes avec un ensemble de permissions plus large.

Ce qu'une liste par plateforme ne peut pas vous dire, et comment 8200.dev y répond

Chaque console vous indique ce qui est autorisé sur cette seule plateforme. Aucune ne vous donne la vue combinée — le même assistant de prise de notes IA connecté à des canaux Slack, à un dépôt GitHub et à une boîte de réception Microsoft 365, chacun avec son propre scope accordé séparément. Agent Guard de 8200.dev lit les trois plateformes avec des scopes en lecture seule et au moindre privilège — pour Slack channels:read, groups:read, files:read, users:read et les scopes de lecture associés, plus un audit de la configuration de l'espace de travail ; pour GitHub read:org, un accès en lecture seule aux dépôts, read:user, l'inventaire des installations, une visibilité en lecture seule sur la facturation Copilot, et read:audit_log ; et pour Microsoft 365 Sites.Read.All, Files.Read.All, Directory.Read.All, Application.Read.All, User.Read.All, Policy.Read.All, Reports.Read.All, AuditLog.Read.All, RoleManagement.Read.Directory et DelegatedPermissionGrant.Read.All — et regroupe tous les résultats des trois plateformes dans un inventaire unique noté par niveau de risque. Le connecteur Microsoft 365 fonctionne avec l'annuaire professionnel ou scolaire Microsoft propre à n'importe quelle organisation, et non un tenant unique et fixe, si bien qu'il se connecte de la même manière que votre organisation soit la seule concernée ou l'une de plusieurs.

Chacun de ces scopes est en lecture seule. Rien ici ne révoque de lui-même l'accès d'une application — cela reste une recommandation qu'une organisation applique délibérément, ou un opt-in explicite pour la règle spécifique qu'elle souhaite automatiser.

Consultez les pages des connecteurs Slack, GitHub et Microsoft 365 pour la liste complète des scopes et ce que chacun analyse.