Mailbox.org, Google, OAuth und Less Secure Applications

Heise schreibt in Mailbox.org: Google sperrt “unsichere” Dritte vom Kalender aus über Anwendungen von Dritten und den Zugriff auf Google Kalender, Google Mail und andere Dienste, die mit GSuite interagieren. Der Artikel wirft leider eine Reihe von Dingen durcheinander, was schade ist, weil er einen wichtigen Punkt machen will.

OAuth2 vs. LSA

Im Artikel geht es um OAuth2 . OAuth2 ist kein neues Verfahren. Es handelt sich um einen Standard, bei dem ein Dienstleister Drittanwendungen den Zugriff auf Dienste erlaubt, indem er der Drittanwendung relativ automatisch ein Logintoken zuteilt, das

1. zeitlich begrenzt ist
2. die Identifikation der Anwendung und
3. des Anwenders erlaubt und
4. einen Scope (einen Satz eingeschränkte Zugriffsrechte) hat.

Um also auf den Google Kalender oder in Zukunft bald auch IMAP zugreifen zu können, muß eine Drittanwendung ein Token vorzeigen. Das Token, das etwa Busycal auf dem Mac verwendet, ist von dem Token verschieden, mit dem ACal+ auf Android auf meinen Google Kalender zugreift. Theoretisch könnte Busycal auch Vollzugriff auf den Kalender haben, während das ACal+ Token einen Read-Only Scope hat.

Beide sind verschieden von meinem mit 2FA gesicherten Zugang zu meinem Google Account, der nicht nur Kalender und Mail enthält, sondern auch mein Wallet, meine gekauften Inhalte, mein Youtube, meinen Google Cloud Zugang und meine Google Ads. Wird durch eine Sicherheitslücke eines der Token publik, ist das kein Beinbruch (der Schaden ist auf den Scope begrenzt) und leicht zu korrigieren (die Zugriffsrechte sind wiederrufbar).

Google gibt einem eine Security-Übersicht für Deinen Account in Google Account . Auf der Permissions -Seite kann man sehen, wer Zugriff hat und was die dürfen. Nach Anklicken sieht man auch, wann das war und man kann den Zugriff wiederrufen.

Permissions Seite für OAuth2 Anwendungen in Google Account .

Das alles ist eine Feine Sache™ und ein großer Fortschritt. In der Vergangenheit hätte man sich bei einem CalDAV oder IMAP Server mit dem Usernamen und Paßwort eingeloggt, und hätte dadurch den gesamten Google Account mit allen Diensten, die da dran hängen, exponiert und gefährdet. In so einem Kontext ist insbesondere der Wiederruf und die Recovery nach einem Security-Problem so gut wie unmöglich.

Das weiß Google auch, und daher gab es bisher für Programme, die OAuth2 nicht beherrschen, eine Sonderlocke: “Application Specific Passwords for Less Secure Applications” (LSA).

“Application Specific Passwords for Less Secure Applications” (LSA) ist auch in Google Account zu finden und hoffentlich leer.

Mit LSA legt man ein Kennwort für seinen Loginnamen fest, das an eine Anwendung gebunden ist und gescoped ist, also im Zugriff beschränkt. Da Google dieses Paßwort generiert, ist es auch sicher vom Accountpaßwort verschieden.

Man kann sich also mit einem Legacy Client, der auch in 2020 noch kein OAuth2 kann, auf einem GMail IMAP oder CalDAV einloggen und riskiert dennoch nicht seinen ganzen Account. Gut so.

OAuth2 Playground

Es gibt einen OAuth2 Playground bei Google. Mit dem und der Entwicklerdokumentation kann man einmal herumspielen. Oder man verwendet deren oauth2.py . Für jeden Dienst gibt es eine Dokumentation, die die OAuth2 Scopes beschreibt, die existieren.

Hier ist die Dokumentation für GMail Scopes . Sie ist wichtig, wir werden weiter unten noch darauf zurück kommen.

Wenn man den OAuth2 Playground einmal durchspielt passiert dies:

Schritt 1: Wähle einen OAuth2 Scope aus, hier gmail.readonly. Auf der rechten Seite sieht man die entsprechenden REST Requests und Responses, sodaß ein Entwickler gleich sehen kann, wie so etwas auf dem Kabel aussieht. In der Praxis wird dieser Schritt vom Anwendungsentwickler ausgeführt und man sieht ihn nicht.

Er legt die Identität der Anwendung fest, so wie sie für den Endanwender nachher in Google Account erscheint.

Führt man diesen Schritt durch, gibt es einen typischen Google Autorisierungscreen: Anwendung Google Playground will Read Access auf unseren Gmail Account. Ist das okay so?

Sagt man ja, gibt es einen Alarm via Push Notification und eine Nachricht in Google Mail: Jemand hat neuen Zugriff auf unseren Account bekommen.

Terror auf meinem Handy: “Google OAuth2 Playground” darf jetzt auf mein GMail.

Das ist auch eine Gute Sache™, denn auf diese Weise ist sichergestellt, daß so ein Zugriff nicht leise und aus Versehen erfolgt.

Mit dem Authorization Code aus Schritt 1 kann die Anwendung sich jetzt ein Zugriffstoken holen, das eine Stunden gilt. Der Grund ist, daß auf diese Weise die Anwendung auf jeden Fall spätestens eine Stunde nach dem Widerruf von Rechten ausgesperrt ist, auch wenn dieses spezifische Token nicht gesondert widerrufen wird.

Und mit diesem Access Token kann die Anwendung dann endlich GMail API Funktionen aus dem Read Only Scope aufrufen, zum Beispiel Identity. Sie kann keine Non-GMail Aktionen ausführen und sie kann auch keine Nachrichten senden, Filter bearbeiten oder ähnliches. Das wäre ein anderer Scope.

Scopes in GMail

Die Liste der Gmail Scopes in der Entwicklerdokumentation klassifiziert Scopes auf verschiedene Weisen, Recommended, Sensitive und Restricted. Die meisten Scopes sind Restricted.

Die Doku sagt weiter:

Restricted—These scopes provide wide access to Google User Data and require you to go through a restricted scope verification process. For information on this requirement, see Google API Services: User Data Policy and Additional Requirements for Specific API Scopes. If you store restricted scope data on servers (or transmit), then you need to go through a security assessment.

Wenn man also eine Serveranwendung (Mailbox.org, Exchange, Open Exchange oder ähnliches) schreibt, und diese Restricted Scope Data runterlädt und speichert, dann wird ein Security Assessment notwendig.

Den Heise Artikel noch einmal lesen

Jetzt lesen wir den Heise Artikel noch einmal.

Da heißt es:

Google forciert den Einsatz von Oauth für seine Mail-, Kalender- und Drive- Dienste, sperrt dabei aber viele Dienstleister und ältere Software aus. Wer bisher beispielsweise Googles Kalender in einer nicht von Google entwickelten Anwendung oder Webseite ohne Oauth integriert, muss sich demnächst entweder umstellen oder darauf hoffen, dass sich sein Anbieter von Google-Partnern in den USA in einem kostspieligen und wenig transparenten Verfahren zertifizieren lässt.

Was heißt das? Der Artikel erklärt das nicht.

Google hat bereits am 30. Oktober letzten Jahres LSA für Business Kunden sanft eingeschränkt. Alle Accounts mit einer leeren LSA Liste haben “LSA erlauben” auf “Nein” gestellt bekommen, für andere Accounts, die LSA Einträge haben, sind andere Einschränkungen gemacht worden.

Ab Mitte diesen Jahres wird LSA weiter eingeschränkt .

Das heißt, zum Zugriff auf Google Dienste wird LSA erschwert oder ganz abgeschaltet und OAuth2 verpflichtend. Soweit eine gute Sache.

Aber: Ein Mailserver hat bisher via LSA Vollzugriff auf einen GMail Account und einen Kalender bekommen, ohne sich dem für Restricted Scopes notwendigem Review zu unterziehen.

Dadurch, daß OAuth2 jetzt verpflichtend wird, werden Firmen wie Open Exchange und Mailbox.org also OAuth2 Reviews aufgezwungen, weil das LSA Schlupfloch nicht mehr existiert. Und das ist genau der Punkt, der beklagt wird, nur daß der Artikel das nicht erklärt.

Mailbox.org-Betreiber Peer Heinlein kritisiert Googles Vorgehen, das ab 15. Januar die Zertifizierung von “Less Secure Apps” vorschreibt. Im Gespräch mit der iX erklärt Heinlein, es sei grundsätzlich nicht verkehrt, wenn unseriöse Anbieter vom Zugriff auf Google-Konten ausgeschlossen werden und Missbrauch minimiert wird.

Das ist irreführtend, weil es primär gar nicht um LSA geht, sondern um OAuth2, und spezifisch um die mit OAuth2 Restricted Scopes verknüpften Audit-Anforderungen. LSA abzuschalten ist eine gute Sache, und LSA zu verwenden, um den Anforderungen für OAuth2 Restricted Scope zu entgehen eine mittelfristig zum Scheitern verurteilte Strategie.

Die Frage, um die es eigentlich gehen muß ist:

Darf Google für den Zugriff auf ihre Plattform einen solchen Audit verlangen oder ist dies eine unzulässige Wettbewerbseinschränkung?

Im Lichte der Entscheidung Banken vs. Sofortüberweisung kann man annehmen, daß es nicht das Problem von Google ist, Anforderungen an die Anwendungen zu stellen, die ein Anwender für seinen Account zuläßt. Insbesondere wenn der Anwender eine Firma ist und der Account Teil eines GSuite Business Accounts ist.

Und das ist die eigentliche Frage, die geklärt werden muß.

OAuth2 ist eine gute Sache. Auch Mailbox.org und OX wissen das und haben das korrekt implementiert, sind dabei aber in die OAuth2 Restricted Scope Requirements für Serverbetreiber gelaufen.