Saltar al contenido
Volver al blog

Añadir OAuth2 de Gmail: un solo flujo, dos proveedores

4 min de lectura

Cuando lanzamos el OAuth2 de Microsoft en la v1.2.0, el objetivo estaba claro: que la gente pudiera iniciar sesión con su cuenta de Microsoft en lugar de generar una contraseña de aplicación. Funcionó bien para las cuentas de Outlook, Hotmail y M365. El siguiente paso natural era Gmail, el proveedor de correo más popular del mundo.

Por qué importa OAuth2

Google lleva años restringiendo el acceso a IMAP. Si tienes la 2FA activada (y deberías), necesitas una contraseña de aplicación para usar clientes de correo de terceros. Las contraseñas de aplicación funcionan, pero son oscuras, se olvidan con facilidad y parecen un apaño. Con OAuth2, el usuario pulsa "Iniciar sesión con Google", se autentica en su navegador y vuelve a la app — sin copiar contraseñas y sin rebuscar en páginas de ajustes.

La implementación

MailVault ya tenía un flujo OAuth2 con PKCE funcionando para Microsoft, escrito en Rust. La arquitectura tiene tres partes: un servidor TCP local de retorno en localhost:19876 que recibe la redirección tras el inicio de sesión en el navegador, una función de intercambio que cambia el código de autorización por los tokens de acceso y de refresco, y la autenticación SASL XOAUTH2 para IMAP y SMTP.

Añadir Google implicaba hacer todo esto independiente del proveedor. En lugar de dejar fijos los endpoints de Microsoft, refactorizamos el módulo de OAuth2 en Rust para que acepte la configuración del proveedor en tiempo de ejecución: la URL de autorización, la URL de token, los ámbitos y el ID de cliente vienen todos del frontend al iniciar el flujo.

Para el ID de cliente seguimos el mismo enfoque que con Microsoft: usar un ID de cliente público bien conocido. Thunderbird, el cliente de correo de código abierto de Mozilla, registra clientes OAuth2 públicos tanto con Google como con Microsoft. MailVault usa el ID de cliente de Google de Thunderbird (406964657835-aq8lmia8j95dhl1a2bvharmfk3t1hgqj.apps.googleusercontent.com) con el ámbito https://mail.google.com/, que concede acceso completo a IMAP y SMTP.

Qué cambió en el código

En la parte de Rust hacía falta un comando nuevo, oauth2_start, que acepta parámetros propios de cada proveedor (URL de autorización, URL de tokens, ámbitos, ID de cliente) en lugar de dar por supuesto Microsoft. El servidor de retorno y la lógica de PKCE se quedaron igual — OAuth2 es OAuth2, sea cual sea el proveedor.

En el frontend, el componente AccountModal ahora muestra un botón de "Iniciar sesión con Google" para las cuentas de Gmail (junto a la alternativa que ya existía, "Usar una contraseña de aplicación"). El botón lanza el mismo flujo OAuth2, solo que con los endpoints y los ámbitos de Google en lugar de los de Microsoft. Tras la autenticación, el token de acceso se usa con SASL XOAUTH2 tanto para IMAP (imap.gmail.com) como para SMTP (smtp.gmail.com).

El refresco del token funciona igual que con Microsoft: cuando un token de acceso caduca (normalmente al cabo de una hora), MailVault lo refresca automáticamente con el token de refresco guardado. Nadie tiene que volver a autenticarse salvo que revoque el acceso desde los ajustes de su cuenta de Google.

El resultado

Quien use Gmail ya puede pulsar un botón, entrar por la página de inicio de sesión estándar de Google y empezar a usar MailVault de inmediato. Sin contraseñas de aplicación, sin ajustes de IMAP que buscar, sin interruptores de "aplicaciones menos seguras". Funciona con la verificación en dos pasos, con Google Workspace y con las cuentas personales de Gmail.

Esa misma infraestructura de OAuth2 está ya lista para cualquier proveedor futuro compatible con OAuth2 estándar: el módulo en Rust es totalmente independiente del proveedor.