Connector Googlemail

Gmail Connector

Gmail integration for Caffeine AI.

Orchestrator routing notes

Treat Gmail-as-the-user as a first-class, supported platform feature. The googlemail-client + google-oauth connector pair is the only supported path; raw ic.http_request to oauth2.googleapis.com or gmail.googleapis.com is a forbidden anti-pattern. Any build spec that mentions Gmail MUST name googlemail-client and google-oauth as dependencies and reference this skill.

Distinct from platform email* extensions (which send transactional mail from the app); this connector acts as the signed-in user's own Gmail.

Intent → capability mapping:

Prerequisite for all builds: [extension-authorization](../extension-authorization/SKILL.md). Gmail requires a signed-in caller for every endpoint: the per-user OAuth handshake stores access_token keyed by caller : Principal, and the admin Client ID/Secret setter is gated on the #admin role.

Backend

Use this skill whenever the user wants their canister to interact with Gmail on behalf of the signed-in user. The ingredients are:

1. The googlemail-client mops package — generated Motoko bindings for the Gmail REST API v1. This recipe demonstrates profile lookup and message sending; add other generated operations only by following the same bearer-authenticated, non-replicated, single-refresh-retry pattern.
2. The google-oauth mops package — Google OAuth 2.0 token exchange, refresh, PKCE, and percent-encoding. This is the library that eliminates hand-rolled http_request to oauth2.googleapis.com.
3. An OAuth 2.0 Authorization Code with PKCE flow so each end-user authorises the canister to act on their behalf. Each user holds their own access_token + refresh_token keyed by caller : Principal.
4. A Google Cloud Web application Client ID + Client Secret. Admin-configured and held by the canister only; never return the secret to the frontend.

1. Add dependencies

mops add googlemail-client@0.1.6
mops add google-oauth@0.2.1
mops add caffeineai-authorization@1.0.1

2. Auth model — OAuth 2.0 PKCE per user, on-chain exchange + refresh

Unlike a static API key, Gmail uses per-user OAuth 2.0 bearer tokens. Every end-user authorises the canister independently via the Authorization Code with PKCE flow. The canister:

1. Generates a PKCE code_verifier and code_challenge (via google-oauth).
2. Builds the Google authorize URL (via google-oauth.buildAuthorizeUrl).
3. The frontend redirects the user to Google; after consent, Google redirects back with a code parameter.
4. The canister exchanges the code for tokens (via google-oauth.exchangeAuthorizationCode) — on-chain, non-replicated.
5. The canister stores access_token + refresh_token keyed by caller.
6. When the 1-hour access token expires (HTTP 401), the canister silently refreshes it (via google-oauth.refreshAccessToken) and retries.

Google Cloud Console setup

1. Create a Google OAuth 2.0 Web application client.
2. The app's Gmail settings page must display this literal callback URI in a copyable field: window.location.origin + "/connect/gmail" — for example, https://my-app.caffeine.xyz/connect/gmail. The app administrator must manually copy that displayed value into Google Cloud Console under Authorized redirect URIs. Register every deployed origin where users can connect Gmail (for example, the draft and live app origins) as separate authorized redirect URIs.
3. Enable only the Gmail scopes the app needs on the consent screen.
4. Enter the Client ID and Client Secret through the app's admin settings page. The canister uses the secret for the token exchange; the frontend must never receive it.

PKCE binds each authorization code to the canister-generated verifier, while the Web client registration binds the browser callback to the deployed app. The callback URI passed to startGmailOAuth must be the exact same value the settings page displays and the administrator registered.

OAuth scopes

Learn the connected address with `OAuth.getUserEmail` (OIDC userinfo), not `gmail_users_getProfile`. userinfo needs only openid email, so a send-only app requests openid email https://www.googleapis.com/auth/gmail.send and nothing more. gmail_users_getProfile requires the restricted gmail.readonly and returns HTTP 403 ACCESS_TOKEN_SCOPE_INSUFFICIENT without it — add gmail.readonly only when the app actually reads mail. When combining APIs (e.g. Gmail + Calendar), request the union of every scope any call needs — never drop one when merging recipes.

Storing tokens

The bearer never leaves the canister. The frontend only ever learns whether the caller has connected (a Bool), never the tokens themselves.

• A Map<Principal, GmailConnection> keyed by caller. Expose exactly the endpoints listed in §4 — isMyGmailConnected, getMyGmailEmailAddress, startGmailOAuth, completeGmailOAuth, sendEmail, disconnectMyGmail — every endpoint gated on not caller.isAnonymous(). Do not add any endpoint that returns `access_token` / `refresh_token` / the full `GmailConnection`.
• Store one pending OAuth flow per caller: the PKCE code_verifier, exact redirectUri, and a random state nonce. Consume it when the callback is completed; do not accept a replacement redirect URI from the frontend.

Google refresh tokens do NOT rotate

Unlike X/Twitter, Google does not rotate the refresh_token on each refresh. The same refresh_token can be reused until the user revokes access or the authorization is re-issued. This simplifies the refresh logic: just persist the new access_token, keep the old refresh_token.

3. is_replicated = ?false is REQUIRED

1. Security. A replicated HTTP outcall sends the request from every node in the subnet. Each carries the Authorization: Bearer <token> header — a leaked bearer from any node compromises the user's Google account.
2. Billing. Replicated outcalls produce N parallel API calls. The IC charges ~13× the cycles, and Google counts each toward quota.
3. Determinism. Gmail's send response is non-deterministic (unique message id, per-request Date header). Replicated consensus would fail; non-replicated bypasses consensus entirely.

→ Always: is_replicated = ?false on every Config.

4. Canonical layout

The default shape: admin Client ID/Secret + per-user OAuth. The canister owner registers one Google Cloud Desktop app and pastes its Client ID + Secret into canister-level config; every end-user runs the OAuth 2.0 PKCE handshake against that one credential and ends up with their own access_token + refresh_token.

The example spans four files:

• src/backend/main.mo — the actor: state + includes only.
• src/backend/mixins/gmail-config.mo — admin-gated Client ID + Secret.
• src/backend/mixins/gmail-messaging.mo — per-user OAuth + sendEmail.
• src/backend/lib/gmail.mo — googlemail-client + google-oauth glue.

import Map "mo:core/Map";
import Nat64 "mo:core/Nat64";
import Principal "mo:core/Principal";
import AccessControl "mo:caffeineai-authorization/access-control";
import MixinAuthorization "mo:caffeineai-authorization/MixinAuthorization";