Das OAuth-Modell ergab Sinn, als eine überschaubare Zahl von der IT freigegebener Apps Zugriff etwa auf den Kalender benötigte. Es trägt jedoch nicht mehr, wenn jeder Mitarbeiter eigenständig KI-Tools, Automatisierungen und Apps direkt mit seiner Google- oder Microsoft-Umgebung verdrahtet — jede mit einem dauerhaften, gescopten Token ohne automatischen Ablauf und ohne zentrale Sichtbarkeit. Das ist keine Fehlkonfiguration, sondern die vorgesehene Funktionsweise von OAuth. Die meisten Sicherheitsprogramme sind schlicht nicht darauf ausgelegt, das im großen Maßstab abzubilden.

Tabellenkalkulationen, so das Fazit der Studie, sind keine Fähigkeit zur Gefahrenabwehr, sondern bestenfalls ein Beleg dafür, wie viel unbekanntes Risiko eine Organisation mit sich trägt. Die Debatte um OAuth-Sichtbarkeit wird oft darauf verengt, dass Beschäftigte sensible Daten ohne Wissen der IT in Drittanbieter-Tools leiten. Das ist ein reales, aber das kleinere Problem. Der dringlichere Punkt: OAuth-Grants sind ein aktiver Angriffsvektor.

Der Drift-Vorfall macht das konkret. Die von Salesloft übernommene Vertriebsplattform unterhielt OAuth-Integrationen mit Salesforce-Instanzen bei Hunderten Kundenunternehmen. Ein von Palo Alto Unit 42 als UNC6395 verfolgter Akteur gelangte — vermutlich über frühere Phishing-Kampagnen — an gültige OAuth-Refresh-Token und nutzte sie, um auf Salesforce-Umgebungen von mehr als 700 Organisationen zuzugreifen.

Die Struktur des Angriffs ist die eigentliche Warnung: Token und Integration waren legitim. Aus Sicht jeder Perimeter-Kontrolle war nichts auffällig. Die Mehr-Faktor-Authentifizierung wurde vollständig umgangen, weil sich der Angreifer nicht anmeldete, sondern ein Token vorlegte, dessen Nutzung Drift bereits gestattet worden war. Einmal im System, exportierte UNC6395 systematisch Daten und durchsuchte sie nach Zugangsdaten: AWS-Zugriffsschlüsseln, Snowflake-Token und Passwörtern. Betroffen waren unter anderem Cloudflare und PagerDuty sowie Dutzende weitere Organisationen; das volle Ausmaß wird laut Quelltext noch ermittelt.

Der Angriff erfolgte nicht über eine verdächtige, unbekannte App, sondern durch eine vertrauenswürdige. Die Lehre lautet nicht, OAuth-Integrationen einzuschränken, sondern: Vertrauen zum Installationszeitpunkt bedeutet nicht, dass eine App vertrauenswürdig bleibt. Genau hier setzen die heute verbreiteten OAuth-Sicherheitswerkzeuge zu kurz an — sie prüfen beim Einrichten, ob ein angeforderter Berechtigungsumfang überzogen ist oder ein Anbieter einen schlechten Ruf hat. Für ein legitimes Tool, dessen Zugangsdaten später gestohlen und missbraucht werden, greift das ins Leere.

Wirksame OAuth-Sicherheit erfordert laut Material Security mehr: die Überwachung des tatsächlichen Verhaltens einer App — der API-Aufrufe und Aktionen — sowie Einblick in die verknüpften Konten. Eine riskante App am Konto eines Praktikanten ist etwas anderes als dieselbe App bei einer Führungskraft mit Zugriff auf sensible E-Mails, Dateien und Systeme.

Material Security stellt seinen OAuth Threat Remediation Agent als Antwort vor. Dieser läuft fortlaufend in der Google-Workspace-Umgebung und überwacht jede OAuth-verbundene Anwendung statt nur neuer Grants. Aus Anbietervertrauen, App-Verhalten und Kontozugriff bildet er ein Risikosignal. Bei hohem Risiko kann er ein Token sofort widerrufen; in unsichereren Fällen bei geschäftskritischen Anwendungen legt er den Fund mit vollem Kontext dem Sicherheitsteam vor. Organisationen legen ihre Schwellenwerte selbst fest — wann automatisch eingegriffen wird und wann eine menschliche Freigabe nötig ist.