OAuth ist gut – doch Google und Microsoft machen daraus ein Zugangstor

Beginnen wir mit dem wichtigsten Punkt: OAuth ist nicht das Problem. Die Abkehr von Basic Authentication, langlebigen Passwörtern und pauschal berechtigten Zugangsdaten war richtig. OAuth ermöglicht begrenzte Berechtigungen, kurzlebige Access Tokens, widerrufbare Verbindungen und eine wesentlich bessere Kontrolle darüber, was eine Anwendung tatsächlich tun darf.

Der Standard selbst ist offen. Er beschreibt, wie eine Anwendung im Auftrag eines Nutzers Zugriff anfragen und erhalten kann. Er schreibt aber nicht vor, dass ein Entwickler zuvor Geschäftsunterlagen, Organisationsnachweise, Demonstrationsvideos oder eine Zulassung durch den Plattformbetreiber vorlegen muss. Diese zusätzliche Ebene entsteht nicht im Protokoll, sondern durch die Regeln der großen Ökosysteme.

Ein offener Standard kann trotzdem zu einem geschlossenen Tor werden

SMTP und IMAP stammen aus einer Welt, in der Interoperabilität ein Grundprinzip des Internets war. Ein Anbieter konnte einen Mailserver betreiben, ein Entwickler einen Client bauen und beide Seiten konnten über dokumentierte Standards miteinander kommunizieren.

OAuth zerstört diese Offenheit nicht. Doch wenn der Zugriff auf eine Mailbox zusätzlich von der Freigabe des Plattforminhabers abhängt, verschiebt sich die entscheidende Frage: Autorisiert der Nutzer eine Anwendung – oder entscheidet am Ende Google beziehungsweise Microsoft, ob diese Anwendung überhaupt autorisierbar sein darf?

Microsoft 365: Nutzerzustimmung endet häufig an der Tenant-Grenze

Bei Microsoft liegt die Hürde häufig nicht in einem Google-ähnlichen Videoreview. Sie entsteht durch das Zusammenspiel aus Microsoft Entra ID, Publisher-Verifizierung, administrativer Zustimmung und den Richtlinien des jeweiligen Microsoft-365-Tenants.

Microsoft empfiehlt Organisationen, die Nutzerzustimmung auf Anwendungen verifizierter Herausgeber und ausgewählte, als risikoarm eingestufte Berechtigungen zu beschränken. Administratoren können die Zustimmung weiter einschränken oder vollständig unterbinden. Damit kann ein Nutzer eine Mailbox-Verbindung ausdrücklich wünschen und trotzdem vor der Meldung stehen, dass eine Administratorfreigabe erforderlich ist.

Für neuere mandantenfähige Anwendungen kann zudem die Publisher-Verifizierung entscheidend werden. Dafür benötigt der Herausgeber unter anderem ein verifiziertes Konto im Microsoft AI Cloud Partner Program und muss dieses mit der App-Registrierung verbinden. Das ist als Vertrauenssignal nachvollziehbar, bindet die Nutzbarkeit einer offenen Autorisierung aber zugleich an Microsofts eigenes Unternehmens- und Partnerverfahren.

Google und Gmail: Wenn die Scope-Prüfung zum Produktengpass wird

Bei Gmail ist der Prozess direkter zentralisiert. Google klassifiziert gmail.send als sensiblen und gmail.readonly als eingeschränkten Scope. Wer diese Zugriffe in einer öffentlichen Anwendung benötigt, muss je nach Nutzung Marken- und Domainnachweise, eine genaue Scope-Begründung und ein Demonstrationsvideo einreichen.

Dieses Video muss den vollständigen OAuth-Ablauf, den exakten Consent Screen und die Funktionen zeigen, die jeden angefragten Scope verwenden. Wird die Begründung nicht akzeptiert oder stimmt die Darstellung aus Sicht des Reviews nicht exakt mit der Anwendung überein, folgen Rückfragen, neue Aufnahmen oder eine erneute Einreichung.

Die offiziellen Zeitangaben verdeutlichen die geschäftliche Wirkung: Google nennt als unverbindliche Richtwerte zwei bis drei Arbeitstage für die Markenprüfung, zehn Arbeitstage für sensible Scopes und bis zu sechs Wochen für eingeschränkte Scopes. Werden eingeschränkte Gmail-Daten auf einem Server gespeichert oder übertragen, kann zusätzlich eine jährlich zu wiederholende Sicherheitsbewertung erforderlich sein.

Warum Hassolux diese Berechtigungen tatsächlich benötigt

Hassolux ist eine Arbeitsplattform für Bau- und Dienstleistungsunternehmen. Projekte, Dokumente, Rechnungen und Kommunikation sollen in einem nachvollziehbaren Arbeitsablauf zusammengeführt werden. Die optionale Mailbox-Verbindung wird von einem berechtigten Nutzer bewusst aktiviert.

Hassolux sucht Nachrichten nur im vom Nutzer ausgewählten Zeitraum, liest Absender, Betreff und Empfangszeit und importiert unterstützte PDF- oder XML-Anhänge für die Rechnungsverarbeitung. Gmail-Nachrichten werden dabei nicht verschoben, markiert, verändert oder gelöscht. Der Versand erfolgt getrennt und ausschließlich nach einer konkreten Nutzeraktion. Die Verbindung kann wieder entfernt und zusätzlich beim Anbieter widerrufen werden.

Genau hier wird die Forderung nach einem „kleineren Scope“ technisch widersprüchlich. Ein Metadaten-Scope liefert keinen Nachrichteninhalt und keine Rechnungsanhänge. Eine Anwendung kann keinen Beleg importieren, den sie nicht lesen darf. gmail.readonly ist deshalb nicht vorsorglich beantragt, sondern die engste Google-Berechtigung, mit der diese sichtbare Funktion umgesetzt werden kann.

Unsere Erfahrung: Demo nach Demo – und trotzdem abgelehnt

Für Hassolux bedeutete die Google-Verifizierung nicht nur eine technische Umsetzung. Wir mussten wiederholt Demonstrationsvideos erstellen, Reviewzyklen abwarten, Status-E-Mails beantworten und erneut erklären, warum der beantragte Scope notwendig ist. Eine Ablehnung wegen genau dieses Scopes nimmt dem Nutzer nicht nur eine abstrakte API-Berechtigung – sie nimmt ihm die Funktion, für die er seine eigene Mailbox ausdrücklich verbinden möchte.

Sensible E-Mail-Daten rechtfertigen eine hohe Sicherheitsanforderung. Eine Prüfung muss aber zwischen übermäßiger Datensammlung und einer technisch notwendigen Minimalberechtigung unterscheiden können. Sonst wird „Least Privilege“ zu einer unerfüllbaren Forderung: Der Plattformbetreiber stellt keinen kleineren passenden Scope bereit, lehnt aber den vorhandenen Scope als zu weitreichend ab.

Was ein fairer Verifizierungsprozess leisten müsste

• Klare, vorab prüfbare Kriterien: Entwickler müssen vor der Implementierung wissen, welche Anwendungsfälle zulässig sind.
• Verbindliche und nachvollziehbare Entscheidungen: Eine Ablehnung sollte die konkrete technische oder datenschutzrechtliche Abweichung benennen.
• Verhältnismäßige Nachweise: Das Prüfverfahren sollte sich an Datenfluss, Speicherort und tatsächlichem Risiko orientieren – nicht primär an der Größe des Herausgebers.
• Wiederverwendbare Prüfungen: Kleine Produktänderungen sollten nicht denselben Beweisprozess von vorn auslösen.
• Ein echter technischer Einspruch: Wenn der Anbieter keinen engeren funktionsfähigen Scope bereitstellt, muss dies im Review berücksichtigt werden.
• Wirksame Nutzerentscheidung: Informierte Zustimmung und ein jederzeitiger Widerruf sollten mehr Gewicht haben als pauschale Plattformgrenzen.

Offene Autorisierung muss offen bleiben

Wir unterstützen OAuth, bessere Authentifizierung und den konsequenten Schutz von Nutzerdaten. Gerade deshalb sollte Kritik an den darübergebauten Zulassungsmechanismen möglich sein. Sicherheit darf Nutzer vor schädlichen Anwendungen schützen. Sie sollte nicht beiläufig Markteintrittsbarrieren erhöhen und die Kontrolle der Plattforminhaber über interoperable Software festigen.

Ein Standard ist auf dem Papier offen. In der Praxis ist er es nur, wenn unabhängige Entwickler, Start-ups und kleinere Softwareunternehmen ihn unter transparenten und fairen Bedingungen nutzen können.

Die Zukunft des Internets sollte nicht davon abhängen, ob eine Handvoll Plattformunternehmen einer technisch notwendigen Integration die Erlaubnis erteilt.

Quellen und weiterführende Dokumentation

• IETF/RFC Editor: OAuth 2.0 Authorization Framework
• Microsoft: Publisher verification overview
• Microsoft: Configure how users consent to applications
• Google: Gmail API scope classifications
• Google: OAuth verification requirements and demo videos
• Google: Test users, authorization expiry and OAuth user caps
• Google: Verification timelines and rejected scopes