Ajouter OAuth2 pour Gmail : un seul flux, deux fournisseurs

Quand nous avons livré OAuth2 pour Microsoft en v1.2.0, l'objectif était clair : permettre aux utilisateurs de se connecter avec leur compte Microsoft existant plutôt que de générer un mot de passe d'application. Cela fonctionnait bien pour les comptes Outlook, Hotmail et M365. L'étape suivante allait de soi : Gmail — le fournisseur d'e-mail le plus utilisé au monde.

Pourquoi OAuth2 compte

Google restreint l'accès à IMAP depuis des années. Si vous avez activé la 2FA (et vous devriez), il vous faut un mot de passe d'application pour utiliser un client de messagerie tiers. Les mots de passe d'application fonctionnent, mais ils sont obscurs, faciles à oublier, et donnent l'impression d'un bricolage. OAuth2 permet à l'utilisateur de cliquer sur « Se connecter avec Google », de s'authentifier dans son navigateur et de revenir dans l'application — aucun mot de passe recopié, aucune page de réglages à explorer.

L'implémentation

MailVault disposait déjà d'un flux OAuth2 PKCE fonctionnel pour Microsoft, écrit en Rust. L'architecture a trois parties : un serveur TCP de rappel local sur localhost:19876 qui reçoit la redirection après la connexion dans le navigateur, une fonction d'échange qui troque le code d'autorisation contre des jetons d'accès et de rafraîchissement, et l'authentification SASL XOAUTH2 pour IMAP et SMTP.

Ajouter Google supposait de rendre tout cela indépendant du fournisseur. Au lieu de coder en dur les points d'accès de Microsoft, nous avons refactorisé le module OAuth2 en Rust pour qu'il accepte la configuration du fournisseur à l'exécution — URL d'autorisation, URL de jeton, portées et identifiant client viennent tous de l'interface au moment où le flux démarre.

Pour l'identifiant client, nous avons suivi la même approche que pour Microsoft : utiliser un identifiant de client public bien connu. Thunderbird, le client de messagerie open source de Mozilla, enregistre des clients OAuth2 publics chez Google comme chez Microsoft. MailVault utilise l'identifiant client Google de Thunderbird (406964657835-aq8lmia8j95dhl1a2bvharmfk3t1hgqj.apps.googleusercontent.com) avec la portée https://mail.google.com/, qui donne un accès IMAP et SMTP complet.

Ce qui a changé dans le code

Côté Rust, il fallait une nouvelle commande oauth2_start qui accepte des paramètres propres au fournisseur (URL d'autorisation, URL de jeton, portées, identifiant client) au lieu de supposer Microsoft. Le serveur de rappel et la logique PKCE n'ont pas bougé — OAuth2 reste OAuth2, quel que soit le fournisseur.

Côté frontend, le composant AccountModal affiche désormais un bouton « Se connecter avec Google » pour les comptes Gmail, à côté de l'option de repli « Utiliser plutôt un mot de passe d'application ». Le bouton déclenche le même flux OAuth2, simplement avec les points d'accès et les portées de Google au lieu de ceux de Microsoft. Après authentification, le jeton d'accès sert à l'authentification SASL XOAUTH2, en IMAP (imap.gmail.com) comme en SMTP (smtp.gmail.com).

Le rafraîchissement des jetons fonctionne exactement comme pour Microsoft : quand un jeton d'accès expire (en général au bout d'une heure), MailVault le renouvelle automatiquement avec le jeton de rafraîchissement stocké. L'utilisateur n'a jamais à se réauthentifier, sauf s'il révoque l'accès depuis les réglages de son compte Google.

Le résultat

Les utilisateurs de Gmail peuvent désormais cliquer sur un bouton, se connecter via la page de connexion standard de Google, et utiliser MailVault immédiatement. Pas de mot de passe d'application, aucun réglage IMAP à chercher, pas d'interrupteur « applications moins sécurisées ». Cela fonctionne avec la 2FA, Google Workspace et les comptes Gmail personnels.

La même infrastructure OAuth2 est maintenant prête pour tout futur fournisseur qui prend en charge OAuth2 standard — le module Rust est entièrement indépendant du fournisseur.