feat: Google OAuth for Gmail and Workspace mailboxes

[lesly]

Why

Gmail and Google Workspace mailboxes can currently only be added with an app password. That works for consumer @gmail.com, but Workspace admins can disable app passwords org-wide, and many do. When they have, there is no way to add that mailbox to MailFlow at all — the connect simply fails with Failed to connect …: Command failed.

The interesting part is that most of the work was already done. makeClientCfg() in imapManager.js and createAccountSmtpTransport() in smtpTransport.js both already accept oauth_provider === 'google' and authenticate over XOAUTH2:

// imapManager.js
// OAuth2 XOAUTH2 for Gmail and Microsoft
if ((account.oauth_provider === 'google' || account.oauth_provider === 'microsoft')
    && account.oauth_access_token) {

But nothing ever produced those tokens. The only OAuth routes were Microsoft's, and both refresh gates were hardcoded to 'microsoft', so even a manually-inserted Google account would have died at the first token expiry. This PR supplies the missing half.

What changed

Google OAuth flow (routes/oauth.js)

• GET /oauth/google and GET /oauth/google/callback, mirroring the Microsoft authorization-code flow: CSRF nonce held in session, id_token verified against Google's JWKS with audience and issuer checks, advisory-locked account upsert to avoid duplicate rows on concurrent callbacks.
• refreshGoogleToken() with the same per-account in-flight dedup map, since the IMAP and SMTP paths can both trip the 5-minute expiry window at once.
• access_type=offline + prompt=consent so a refresh token is always issued. If one is missing the grant is rejected outright rather than persisting an account that would silently stop working an hour later.
• invalid_grant on refresh is surfaced as a reconnect prompt instead of a generic failure, since no retry can fix a revoked grant.

Refresh gates generalised (imapManager.js, smtpTransport.js)

Replaced account.oauth_provider !== 'microsoft' equality checks with a provider lookup table, so adding a third provider later doesn't mean finding every branch again.

Integrations config generalised (routes/integrations.js)

save, delete, and the startup loadIntegrationConfigs() each had a duplicated per-provider if block. Collapsed to a single PROVIDER_ENV table. /integrations/status now reports google.

Connect UI (AdminPanel.jsx)

A Gmail / Google Workspace card alongside the Microsoft one: setup steps, credential form, connect button, non-admin capability note.

Drive-by fix, affects Microsoft too

The connect button was gated on configs.<provider>?.clientId, which only reflects config written through the admin UI into integration_config. A provider configured via plain .env vars reports configured: true from /integrations/status but has no DB row — so on an env-only install, an admin saw a permanently disabled connect button while a non-admin saw a working one. Capability status is now fetched for admins too and both sources are consulted.

No schema change

The oauth_* columns on email_accounts are already provider-agnostic. Nothing to migrate.

A note on Google's restricted scope

https://mail.google.com/ is a restricted scope, and the consent screen configuration decides whether this is actually usable. Worth stating plainly because the obvious choice is the wrong one:

Consent screen	Verification	Refresh token lifetime
Internal (project owned by a Workspace org)	none	permanent
External + Testing	none	revoked after 7 days
External + In production	full review incl. security assessment	permanent

External + Testing looks like the easy path for self-hosters and is what I initially assumed, but Google revokes refresh tokens after 7 days in that mode, so every account would need reconnecting weekly. Internal is the configuration that works. Consumer @gmail.com accounts cannot be covered by an Internal app, but those can still use an app password, and this flow is aimed squarely at the Workspace case where that option has been taken away.

This is documented in .env.example, in a comment above GOOGLE_SCOPE, and in the setup panel in the UI.

Testing

• Backend: 995 passing. Added coverage for the Google refresh branch, the still-valid-token no-op, and google in the integrations status payload.
• Frontend: suite passing, including the i18n key-coverage, source-coverage and value-uniqueness checks.
• Both lints clean, frontend builds.

The google i18n block is added to all seven locales with real translations rather than English placeholders. Three brand/placeholder keys and one genuine fr/it collision (ID client) are added to SAME_VALUE_ALLOWED.

Verified against a live Workspace mailbox

Not just unit tests — this was run against a real Google Workspace account whose admin has app passwords disabled:

• Account connects and syncs over XOAUTH2, no password stored anywhere.
• Refresh path exercised deliberately by forcing oauth_token_expiry into the past and triggering a reconnect: Refreshing google token for … → reconnected, expiry moved forward, refresh token preserved by the COALESCE (Google does not reissue one on refresh).
• An existing app-password Gmail account on the same instance was unaffected.

Happy to adjust anything — particularly if you'd rather the Google config live somewhere other than alongside Microsoft's, or if you want the consent-screen guidance worded differently.