Google Calendar MCP OAuth Proxy

Este Worker actúa como el límite de OAuth entre un cliente MCP como Codex y el MCP oficial de Calendar de Google.

Codex / MCP client
        |
        | OAuth to this Worker
        v
Cloudflare OAuth Provider
        |
        | Google OAuth (client ID + client secret)
        v
Google OAuth
        |
        | Google access token
        v
Google Calendar MCP
https://calendarmcp.googleapis.com/mcp/v1

El cliente nunca recibe el secreto de cliente OAuth de Google. Los datos confidenciales y tokens de refresh de Google se almacenan en las propiedades cifradas de la concesión OAuth gestionadas por el proveedor de OAuth de Cloudflare. El manejador protegido /mcp reemplaza el token Bearer local del cliente por el token de acceso de Google del usuario antes de reenviar el tráfico MCP al destino.

Ámbitos de Google Calendar

wrangler.jsonc define los ámbitos de Calendar de Google en GOOGLE_OAUTH_SCOPES:

https://www.googleapis.com/auth/calendar.calendarlist.readonly
https://www.googleapis.com/auth/calendar.events.freebusy
https://www.googleapis.com/auth/calendar.events.readonly
https://www.googleapis.com/auth/calendar.calendars

El worker añade automáticamente email profile porque el callback usa el endpoint de información de usuario de Google para identificar al usuario autorizado.

La solicitud de autorización de Google también utiliza access_type=offline y prompt=consent para que Google devuelva un token de actualización.

Related MCP server: google-mcp-server

Secretos locales

Copia el archivo de ejemplo:

cp .dev.vars.example .dev.vars

Establece:

GOOGLE_CLIENT_ID=<Google OAuth web client ID>
GOOGLE_CLIENT_SECRET=<Google OAuth client secret>
COOKIE_ENCRYPTION_KEY=<strong random secret>
HOSTED_DOMAIN=<optional Google Workspace domain restriction>

GOOGLE_OAUTH_SCOPES y GOOGLE_MCP_URL son variables de worker no secretas en wrangler.jsonc.

Cliente OAuth de Google Cloud

Usa un cliente de aplicación web de OAuth de Google.

El URI de redirección autorizado debe ser el nombre de host público de este Worker o túnel más /callback:

https://mcp-auth.example.com/callback

Añade los ámbitos de Calendar listados anteriormente a la configuración de consentimiento/acceso a datos de Google Auth Platform.

Ejecutar localmente

Instala las dependencias y genera los tipos del Worker:

npm install
npm run cf-typegen

Inicia Wrangler localmente en el puerto 5555:

npm run dev

El endpoint local es:

http://localhost:5555/mcp

OAuth requiere un callback HTTPS público, así que para pruebas locales de extremo a extremo usa un Cloudflare Tunnel.

Túnel con nombre estable

Un nombre de host estable es preferible porque el mismo callback debe registrarse en Google Cloud.

npx wrangler dev --tunnel-name=mcp-google-auth --tunnel

Configura el nombre de host del túnel con nombre para que apunte al servidor de desarrollo de Wrangler. Por ejemplo:

https://mcp-auth.example.com  ->  local Wrangler dev server

Luego registra:

https://mcp-auth.example.com/callback

como el URI de redirección de OAuth de Google.

La URL MCP expuesta a Codex es:

https://mcp-auth.example.com/mcp

Configuración de Codex

Como este Worker es el servidor de autorización OAuth que ve Codex, Codex no necesita el ID de cliente de Google ni el secreto de cliente de Google.

[mcp_servers.google_calendar_proxy]
enabled = true
url = "https://mcp-auth.example.com/mcp"
auth = "oauth"

Luego autentícate:

codex mcp login google_calendar_proxy

El flujo esperado es:

1. Codex descubre los endpoints del OAuth de este Worker.

2. Codex se registra/autentica con este Worker.

3. El Worker envía el navegador a Google.

4. Google redirige a /callback en el Worker/túnel.

5. El Worker intercambia el código de autorización de Google usando GOOGLE_CLIENT_SECRET.

6. Codex recibe un token OAuth emitido por el Worker.

7. Las llamadas a /mcp se reenvían al MCP oficial de Calendar de Google usando el token de acceso de Google del usuario.

Comportamiento de emisión de tokens de refresh

El token de refresh de Google se retiene en las props cifradas de la concesión de OAuth. El proxy mantiene una caché LRU acotada y local al isolate con los tokens de acceso de Google, elimina las entradas cuando alcanzan la ventana de refresh y limita la caché a 100 usuarios. Si el token de acceso almacenado caduca, o si el MCP de Google devuelve 401, el Worker usa el token de refresh de Google junto con el secreto de cliente del lado del Worker para generar un nuevo token de acceso de Google y reintentar una vez.

La memoria caché en memoria es solo una optimización. Un nuevo isolate del Worker siempre puede actualizar desde las tiendas cifradas de la concesión.

Protocolos heredados

Las concesiones de OAuth creadas antes de permitir el token de refresh contienen solo el token de acceso original de Google y los metadatos del usuario. El proxy detecta estas concesiones y continúa usando su token de acceso existente mientras Google lo acepta. Cuando Google rechaza ese token, el Worker devuelve 401 invalid_token para que la conexión MCP pueda ser reautorizada en lugar de intentar actualizar con credenciales faltantes.