Gmail-OAuth2 ergänzen: ein Ablauf, zwei Anbieter

Als wir in v1.2.0 Microsoft-OAuth2 ausgeliefert haben, war das Ziel klar: Nutzerinnen und Nutzer sollten sich mit ihrem bestehenden Microsoft-Konto anmelden können, statt ein App-Passwort zu erzeugen. Für Outlook-, Hotmail- und M365-Konten hat das gut funktioniert. Der naheliegende nächste Schritt war Gmail — der beliebteste E-Mail-Anbieter der Welt.

Warum OAuth2 zählt

Google zieht den Zugang zu IMAP seit Jahren enger. Wenn du 2FA aktiviert hast (und das solltest du), brauchst du ein App-Passwort, um Mailclients von Drittanbietern zu nutzen. App-Passwörter funktionieren, aber sie sind versteckt, leicht zu vergessen und fühlen sich wie ein Behelf an. Mit OAuth2 klickt man auf „Mit Google anmelden“, authentifiziert sich im Browser und kommt zur App zurück — kein Passwort kopiert, keine Einstellungsseiten durchsucht.

Die Umsetzung

MailVault hatte bereits einen funktionierenden OAuth2-PKCE-Ablauf für Microsoft, geschrieben in Rust. Die Architektur hat drei Teile: einen lokalen TCP-Callback-Server auf localhost:19876, der die Weiterleitung nach der Anmeldung im Browser entgegennimmt, eine Funktion für den Token-Austausch, die den Autorisierungscode gegen Access- und Refresh-Token tauscht, und XOAUTH2-SASL-Authentifizierung für IMAP und SMTP.

Google zu ergänzen hieß, all das anbieterunabhängig zu machen. Statt Microsofts Endpunkte fest zu verdrahten, haben wir das Rust-OAuth2-Modul so umgebaut, dass es die Anbieterkonfiguration zur Laufzeit annimmt — Autorisierungs-URL, Token-URL, Scopes und Client-ID kommen alle vom Frontend, wenn der Ablauf gestartet wird.

Für die Client-ID sind wir denselben Weg gegangen wie bei Microsoft: eine allgemein bekannte öffentliche Client-ID nutzen. Thunderbird, der quelloffene Mailclient von Mozilla, registriert öffentliche OAuth2-Clients sowohl bei Google als auch bei Microsoft. MailVault nutzt Thunderbirds Google-Client-ID (406964657835-aq8lmia8j95dhl1a2bvharmfk3t1hgqj.apps.googleusercontent.com) mit dem Scope https://mail.google.com/, der vollen IMAP- und SMTP-Zugriff gewährt.

Was sich im Code geändert hat

Auf der Rust-Seite brauchte es einen neuen Befehl oauth2_start, der anbieterspezifische Parameter entgegennimmt (Auth-URL, Token-URL, Scopes, Client-ID), statt Microsoft vorauszusetzen. Der Callback-Server und die PKCE-Logik blieben gleich — OAuth2 ist OAuth2, egal bei welchem Anbieter.

Im Frontend zeigt die Komponente AccountModal jetzt bei Gmail-Konten einen Button „Mit Google anmelden“ (neben dem bestehenden Ausweichweg „Stattdessen App-Passwort verwenden“). Der Button stößt denselben OAuth2-Ablauf an, nur mit Googles Endpunkten und Scopes statt Microsofts. Nach der Authentifizierung wird der Access-Token per XOAUTH2 SASL sowohl für IMAP (imap.gmail.com) als auch für SMTP (smtp.gmail.com) verwendet.

Die Token-Erneuerung funktioniert genauso wie bei Microsoft: Läuft ein Access-Token ab (typischerweise nach einer Stunde), erneuert MailVault es automatisch mit dem gespeicherten Refresh-Token. Du musst dich nie neu anmelden, außer du entziehst den Zugriff in deinen Google-Kontoeinstellungen.

Das Ergebnis

Gmail-Nutzerinnen und -Nutzer klicken jetzt einen Button, melden sich über Googles Standard-Anmeldeseite an und können MailVault sofort verwenden. Keine App-Passwörter, keine IMAP-Einstellungen zu suchen, keine Schalter für „weniger sichere Apps“. Es funktioniert mit 2FA, mit Google Workspace und mit privaten Gmail-Konten.

Dieselbe OAuth2-Infrastruktur ist jetzt bereit für jeden künftigen Anbieter, der Standard-OAuth2 unterstützt — das Rust-Modul ist vollständig anbieterunabhängig.