So auditieren Sie Drittanbieter-OAuth-Apps in Slack, GitHub und Microsoft 365

Um Drittanbieter-OAuth-Apps zu auditieren, prüfen Sie die jeweils eigene Autorisierungsliste jeder Plattform separat: die Seite „Installed Apps“ von Slack, die OAuth-App-Richtlinie der GitHub-Organisation und die Liste der Enterprise-Anwendungen in Microsoft Entra. Jede zeigt einen anderen Ausschnitt desselben zugrunde liegenden Problems – welche Apps auf Ihre Daten zugreifen können – und keine zeigt die jeweils anderen beiden.

Dieser Leitfaden nennt den genauen Pfad für jede Plattform, was dort angezeigt wird und wo eine plattformspezifische Prüfung an ihre Grenzen stößt.

Wo sehe ich autorisierte OAuth-Apps in Slack?

Gehen Sie zu Settings & administration → Manage apps, wodurch der Slack Marketplace geöffnet wird, beschränkt auf Ihren Workspace, und wählen Sie dann oben in der Seitenleiste Installed Apps. Diese Funktion ist in jedem Slack-Plan verfügbar und listet jede installierte App mit den genehmigten Scopes auf.

Bei Enterprise Grid ergänzt der Bereich Integrations im Admin-Dashboard eine organisationsweite Ansicht über alle Workspaces hinweg. Diese Cross-Workspace-Ansicht basiert auf dem Scope admin.apps:read, der auf Enterprise Grid beschränkt ist und – selbst dort – nur zeigt, welche Apps genehmigt, eingeschränkt oder ausstehend sind; er gibt in diesem selben Aufruf nicht die vollständige Scope-Liste jeder App preis. Bei einem einzelnen Workspace bleibt die Seite „Installed Apps“ die verlässliche Quelle dafür, was eine App tatsächlich kann.

Wo sehe ich autorisierte OAuth-Apps in GitHub?

Gehen Sie zu Settings → Third-party Access → OAuth app policy Ihrer Organisation. Neue Organisationen haben standardmäßig Zugriffsbeschränkungen für OAuth-Apps aktiviert, sodass Mitglieder auf dieser Seite auch den Zugriff auf eine neue App beantragen und ein Owner ihn genehmigen oder ablehnen kann. Um eine zuvor genehmigte App zu widerrufen, suchen Sie sie in derselben Liste und wählen Deny access.

GitHub Apps (ein von klassischen OAuth Apps getrennter Mechanismus, den die meisten modernen Integrationen nutzen) werden an anderer Stelle überprüft: Unter der Organisation Settings → Integrations → GitHub Apps (oder Installed GitHub Apps) wird aufgelistet, was installiert ist und auf welche Repositories jede App zugreifen kann.

Seit 2026 kann eine Organisation zudem abgestufte Kontrollen darüber festlegen, wer überhaupt berechtigt ist, eine neue App zu *beantragen* – unter Settings → Third-party Access: Sowohl Mitglieder als auch externe Mitarbeiter können Apps beantragen (die langjährige Standardeinstellung), externe Mitarbeiter können blockiert werden, während Mitglieder weiterhin beantragen können, oder beide Gruppen können vollständig daran gehindert werden, überhaupt eine App zu beantragen – wodurch der Prüfbereich schon eingeschränkt wird, bevor eine Anfrage die Warteschlange eines Owners erreicht. Die organisationsweite Zugriffsbeschränkung für OAuth-Apps selbst kann ebenfalls vollständig deaktiviert werden, wodurch der Genehmigungsschritt für jedes Mitglied entfällt – eine Einstellung, deren aktiver Status geprüft werden sollte, bevor man die OAuth-App-Richtlinienliste als vollständige Aufzeichnung dessen betrachtet, was autorisiert wurde.

Wo sehe ich autorisierte OAuth-Apps in Microsoft 365?

Melden Sie sich beim Microsoft Entra Admin Center an und gehen Sie zu Identity → Applications → Enterprise applications → All applications. Wählen Sie eine App aus, dann Permissions. Der Tab Admin consent zeigt die für den gesamten Tenant erteilten Berechtigungen – und diese können dort direkt widerrufen werden. Der Tab User consent zeigt, was einzelne Benutzer für sich selbst genehmigt haben – und das Portal bietet dafür keine Schaltfläche zum Widerrufen; die Rücknahme erfordert einen Microsoft-Graph-API-Aufruf oder ein von jemandem mit der Rolle Cloud Application Administrator ausgeführtes PowerShell-Cmdlet. Blockiert ein Tenant Benutzerzustimmung grundsätzlich, kann ein Global Administrator stattdessen einen Admin-Consent-Workflow aktivieren, sodass eine blockierte Anfrage überprüfbar wird, statt in einer Sackgasse zu enden – im Microsoft 365 Access Guide erfahren Sie genau, wie diese Prüfwarteschlange funktioniert.

Warum ist eine plattformspezifische Prüfung schwer aktuell zu halten?

Drei Konsolen, drei Formate, drei unterschiedliche Admin-Rollen, die schon erforderlich sind, um sie überhaupt zu öffnen. Slacks organisationsweite programmatische Ansicht benötigt Enterprise Grid; Microsofts benutzerbezogene Freigaben erfordern PowerShell oder Graph statt eines Klicks im Portal; GitHub trennt klassische OAuth Apps von GitHub Apps in zwei unterschiedliche Listen, die ein Admin wissen muss, separat zu prüfen. Slack unterteilt zudem seine eigene Installed-Apps-Ansicht in die Tabs Approved, Restricted und Requests, sodass ein vollständiger Durchgang bedeutet, drei Filter zusätzlich zu den drei Plattformen zu prüfen. Keine der drei Plattformen bewertet eine App nach Risiko, und keine sagt Ihnen, ob derselbe Anbieter auch auf den anderen beiden Plattformen verbunden ist – dort möglicherweise mit einem umfassenderen Satz an Berechtigungen.

Was eine plattformspezifische Liste Ihnen nicht sagen kann, und wie 8200.dev das beantwortet

Jede Konsole zeigt, was auf genau dieser einen Plattform autorisiert ist. Keine zeigt das Gesamtbild – etwa denselben KI-Notizassistenten, der mit Slack-Kanälen, einem GitHub-Repository und einem Microsoft-365-Postfach verbunden ist, jeweils mit separat erteiltem Scope. 8200.devs Agent Guard liest alle drei mit Least-Privilege-, Nur-Lese-Scopes aus – bei Slack channels:read, groups:read, files:read, users:read und verwandte Read-Scopes sowie eine Prüfung der Workspace-Konfiguration; bei GitHub read:org, schreibgeschützten Repo-Zugriff, read:user, ein Installationsinventar, schreibgeschützte Copilot-Abrechnungseinsicht und read:audit_log; und bei 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 und DelegatedPermissionGrant.Read.All – und fasst jeden Befund aus allen dreien in einem einzigen risikobewerteten Inventar zusammen. Der Microsoft-365-Connector funktioniert mit dem eigenen Microsoft-Arbeits- oder Schulverzeichnis jeder Organisation, nicht mit einem einzigen festen Tenant, und verbindet sich damit auf dieselbe Weise, egal ob Ihre Organisation die einzige im Bild ist oder eine von mehreren.

Jeder dieser Scopes ist nur lesend. Nichts hier widerruft von sich aus den Zugriff einer App – das bleibt eine Empfehlung, der eine Organisation bewusst folgt, oder ein ausdrückliches Opt-in für die konkrete Regel, die automatisiert werden soll.

Die vollständige Scope-Liste und Informationen dazu, was jeder Connector scannt, finden Sie auf den Connector-Seiten Slack, GitHub und Microsoft 365.