Google Connectors Setup

How to create the Google Cloud OAuth app that powers the Google connectors - gmail, google-calendar, and google-drive - for a university, and wire it into CampusCore. The three connectors share one OAuth app; each university creates its own app in its own Google Cloud organization - CampusCore never shares an OAuth app between clients.

What the connectors do

The Google connectors give the assistant delegated access to Gmail, Google Calendar, and Google Drive on behalf of each connected user - one connector per product, so admins enable, test, and govern each product independently, and each user connection carries a token scoped to that product alone. Every call runs on that user's own OAuth token, so Google enforces all data scoping - the assistant can never see mail, events, or files the user cannot see. Write actions (drafting, sending, organizing mail, creating or changing events, creating, sharing, or trashing files) are held for in-chat user confirmation and are additionally disabled per role until a workspace admin enables them. The google-drive connector also serves knowledge-folder imports: the cloud-import picker browses and downloads Drive files through it.

1. Create a Google Cloud project

Sign in to the Google Cloud Console with an account in the university's Google Workspace organization.

1. Create a new project (e.g. CampusCore Assistant) under the university's organization.
2. In APIs & Services -> Library, enable the API for each connector the university will run: the Gmail API, the Google Calendar API, and the Google Drive API.

2. Configure the OAuth consent screen

Under APIs & Services -> OAuth consent screen (Google Auth Platform):

1. User type: Internal. This is the load-bearing choice: gmail.modify and drive are Google restricted scopes, and an External app requesting them must pass Google's CASA security verification before anyone outside a 100-user test list can connect. An Internal app is exempt - only accounts in the university's own Workspace organization can authorize it, which is also the right access posture. A deployment running only the google-calendar connector requests no restricted scope at all - one reason the products are separate connectors.
2. Fill in the app name (e.g. CampusCore), user support email, and developer contact email.
3. On the Scopes page add the scopes for the connectors the university will run:
4. https://www.googleapis.com/auth/gmail.modify (gmail)
5. https://www.googleapis.com/auth/calendar (google-calendar)
6. https://www.googleapis.com/auth/drive (google-drive)

Each connector's own OAuth flow asks only for its product's scope, so a user's gmail token cannot touch files and their google-drive token cannot read mail. gmail.modify covers reading, searching, drafting, sending, and organizing mail but explicitly excludes permanent deletion - the connector can move a message to trash (recoverable for 30 days) and nothing stronger. The drive scope is full Drive access on the user's own files; the connector's file surface likewise stops at trash (recoverable), never a permanent delete.

3. Create the OAuth client

Under APIs & Services -> Credentials -> Create Credentials -> OAuth client ID:

1. Application type: Web application.
2. Under Authorized redirect URIs, add one URI per connector:
3. https://<your-campuscore-domain>/api/connectors/gmail/callback
4. https://<your-campuscore-domain>/api/connectors/google-calendar/callback
5. https://<your-campuscore-domain>/api/connectors/google-drive/callback
6. Create, then copy the Client ID and Client Secret.

If the university runs any other integration against Google OAuth, give it its own OAuth client rather than reusing this one. Beyond the different redirect URIs, the real hazard is revocation: Google's /revoke endpoint kills the whole grant behind a client id, so with a shared client a user disconnecting one integration would silently break the other. The three CampusCore connectors share this one client safely because CampusCore accounts for it: disconnecting one Google product revokes at Google only when no other connected Google product of that user runs on the same client id.

4. Configure the connectors in CampusCore

In CampusCore, go to Settings -> Workspace Connectors and open Configure on the first Google connector you set up. Enter the Client ID and Client Secret there and tick Offer this configuration for sibling connectors to copy. Each remaining Google connector then shows a Copy from ... option in its configuration form - use it, and the client credentials are copied over and kept linked, so rotating them on the origin can update every linked connector in one save. Redirect URI and Scopes are per-connector and stay editable on every member.

Field	Value	Scope
Client ID	the OAuth client ID	copyable across the family
Client Secret	the OAuth client secret	copyable across the family
Redirect URI	that connector's exact URI from step 3	per connector
Scopes	leave the default unless the university narrows the surface	per connector

Enable each connector the university wants, then enable its write actions per role under the same screen - all writes ship disabled by design, so nothing can send or change data until an admin scopes it in. Enabling one product and testing it before connecting the others is the intended rollout path.

Narrowing a connector's Scopes narrows what every user's token for that connector can do; for example replacing gmail.modify with gmail.readonly makes drafting and organizing impossible platform-wide while keeping search and reading, and replacing drive with drive.readonly keeps file browsing and loading while disabling every file write. A user who connected before a scope widening must disconnect and reconnect to pick up the new grant; until they do, an action needing the new scope fails and marks their connection as needing reconnection. A connector that saved its own Scopes value keeps it across upgrades - after an upgrade that widens the default scopes, edit the saved value to match or the new surface stays unreachable. One exception: the upgrade that split the former Google Workspace suite into these three connectors dropped the suite's saved Scopes value (a suite-wide string is wrong for every product) - a university that had narrowed the suite must re-narrow the affected product connector.

5. Verify

Connect a test account from Settings -> Connected Services on each enabled connector, confirm the granted-scope chips show that connector's scope, and ask the assistant something like "summarize my new email since yesterday" (gmail) or "what is on my calendar Thursday" (google-calendar) or "what files are in my Drive" (google-drive).

Development fallback (consumer Google accounts)

For local development without a Workspace organization, the consent screen can instead be External and stay in Testing publishing status, with each developer's Gmail address added as a test user (up to 100). Testing mode is exempt from CASA verification; Google shows an "unverified app" interstitial at consent, refresh tokens expire after 7 days, and consumer accounts cannot serve other people's free/busy unless those calendars are explicitly shared. Never use the External configuration for a university deployment.