Google Calendar MCP OAuth Proxy

Dieser Worker fungiert als OAuth-Grenze zwischen einem MCP-Client wie Codex und dem offiziellen Google Calendar MCP.

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

Der Client erhält niemals das Google-OAuth-Clientgeheimnis. Google-Zugriffs- und Refresh-Tokens werden in den verschlüsselten OAuth-Grant-Eigenschaften gespeichert, die vom Cloudflare-OAuth-Anbieter verwaltet werden. Der geschützte /mcp-Handler ersetzt das lokale Bearer-Token des Clients durch das Google-Zugriffstoken des Benutzers, bevor er den MCP-Datenverkehr an den Upstream weiterleitet.

Google-Scopes

wrangler.jsonc definiert die Google Calendar-Scopes in 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

Der Worker fügt automatisch email profile hinzu, weil der Callback den user-info-Endpunkt von Google verwendet, um den autorisierten Benutzer zu identifizieren.

Die Google-Autorisierungsanfrage verwendet außerdem access_type=offline und prompt=consent, damit Google ein Refresh-Token zurückgibt.

Related MCP server: google-mcp-server

Lokale Geheimnisse

Kopieren Sie die Beispieldatei:

cp .dev.vars.example .dev.vars

Legen Sie fest:

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 und GOOGLE_MCP_URL sind nicht geheime Worker-Variablen in wrangler.jsonc.

Google Cloud OAuth-Client

Verwenden Sie einen Google-OAuth-Client für Webanwendungen.

Der autorisierte Redirect-URI muss der öffentliche Hostname dieses Workers oder Tunnels plus /callback sein:

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

Fügen Sie die oben aufgeführten Calendar-Scopes zur Konfiguration für Einwilligung/Datenzugriff der Google Auth-Plattform hinzu.

Lokal ausführen

Installieren Sie die Abhängigkeiten und generieren Sie die Worker-Typen:

npm install
npm run cf-typegen

Starten Sie Wrangler lokal auf Port 5555:

npm run dev

Der lokale Endpunkt ist:

http://localhost:5555/mcp

OAuth erfordert einen öffentlichen HTTPS-Callback. Verwenden Sie für lokale End-to-End-Tests einen Cloudflare Tunnel.

Stieder benannter Tunnel

Ein stabiler Hostname ist vorzuziehen, weil derselbe Callback in Google Cloud registriert werden muss.

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

Konfigurieren Sie den Hostnamen des benannten Tunnels so, dass er Anfragen an den Wrangler-Entwicklungsserver weiterleitet. Zum Beispiel:

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

Registrieren Sie dann:

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

als Google-OAuth-Redirect-URI.

Die für Codex bereitgestellte MCP-URL lautet:

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

Codex-Konfiguration

Da dieser Worker für Codex der OAuth-Autorisierungsserver ist, benötigt Codex weder die Google-Client-ID noch das Google-Clientgeheimnis.

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

Dann authentifizieren Sie sich:

codex mcp login google_calendar_proxy

Der erwartete Ablauf ist:

1. Codex entdeckt die OAuth-Endpunkte dieses Workers.

2. Codex registriert/authentifiziert sich bei diesem Worker.

3. Der Worker sendet den Browser an Google.

4. Google leitet zum /callback auf dem Worker/Tunnel zurück.

5. Der Worker tauscht den Google-Autorisierungscode mithilfe von GOOGLE_CLIENT_SECRET aus.

6. Codex erhält ein vom Worker ausgestelltes OAuth-Token.

7. Aufrufe an /mcp werden an den offiziellen Google Calendar MCP weitergeleitet, wobei das Google-Zugriffstoken des Benutzers verwendet wird.

Verhalten bei der Token-Aktualisierung

Googles Refresh-Token wird in den verschlüsselten OAuth-Grant-Eigenschaften aufbewahrt. Der Proxy unterhält einen begrenzten, auf die jeweilige Isolate beschränkten LRU-Cache für Google-Zugriffstokens, entfernt Einträge, sobald sie das Aktualisierungsfenster erreichen, und begrenzt den Cache auf 100 Benutzer. Wenn das gespeicherte Zugriffstoken abgelaufen ist oder Googles MCP 401 zurückgibt, verwendet der Worker das Google-Refresh-Token sowie das Worker-seitige Clientgeheimnis, um ein neues Google-Zugriffstoken zu erzeugen, und wiederholt den Aufruf einmal.

Der In-Memory-Cache ist nur eine Optimierung. Eine neue Worker-Isolate kann jederzeit die Tokens aus den verschlüsselten Grant-Eigenschaften aktualisieren.

Legacy grants

Legacy-Grants, die vor der Unterstützung von Refresh-Tokens erstellt wurden, enthalten nur das ursprüngliche Google-Zugriffstoken sowie Benutzermetadaten. Der Proxy erkennt diese Grants und verwendet weiterhin ihr vorhandenes Zugriffstoken, solange Google es akzeptiert. Sobald Google dieses Token ablehnt, gibt der Worker 401 invalid_token zurück, damit die MCP-Verbindung neu autorisiert werden kann, anstatt eine Aktualisierung mit fehlenden Anmeldedaten zu versuchen.