Skip to main content
This guide configures the Autopilot dashboard to sign users in with Google OAuth/OIDC instead of Xano. It is an alternative to the default Xano method; exactly one method is active per cluster. Authorization (who can do what) is unchanged — a Google-authenticated user is resolved against the same AccessPolicy by email. Auth is gated by auth.enabled (default false). Enabling Google on a cluster is a deliberate, per-cluster opt-in. Rollback is instant: flip the method back to xano or set auth.enabled=false and redeploy.

​
Prerequisites

  • A Google Cloud project where you can create OAuth credentials.
  • The dashboard’s external base URL (the dashboard hostname), e.g. https://ops.xano.com. The OAuth redirect URI is always <base>/api/v1/auth/callback.
  • A Google Workspace domain to enforce (e.g. xano.com) — strongly recommended.

​
1. Create the OAuth client

In the GCP Console → APIs & Services → Credentials → Create credentials → OAuth client ID:
  • Application type: Web application
  • Authorized redirect URIs: add <base>/api/v1/auth/callback for every hostname that will use Google on this cluster, e.g. https://ops.xano.com/api/v1/auth/callback. (The path is always /api/v1/auth/callback.)
Note the generated Client ID and Client secret.

​
2. Create the client-secret Secret

The client secret is injected from a Kubernetes Secret (read by the kubelet) — it is never placed in Helm values or git.
The key name (client-secret) is the Helm default (auth.google.clientSecret.secretKey).

​
3. Set Helm values

In the cluster’s env file (deploy/envs/<tier>/<cluster>.yaml) or a values override:
Hosted-domain enforcement is on by default. Either set allowedDomain, or explicitly set allowAnyDomain: true to accept any Google account (including consumer @gmail.com, which carry no hd claim). The controller refuses to start a method=google cluster unless one of these is satisfied (and clientId + the secret are present) — a fail-fast startup error, not a silent lockout.

​
4. Deploy and verify

Deploy the cluster as usual:
Verify:
  1. Open the dashboard → you should be redirected to /login, which now shows “Sign in with Google” with the Google glyph.
  2. Click it → Google’s account chooser appears (scoped to the allowed domain via the hd hint) → after consent you land back on /app/.
  3. A first-time user with no grant lands on the access-request screen; an admin approves them on the Access Control → Pending Requests page.
Lockout insurance: set superAdmins (e.g. you@xano.com) — a super-admin resolves to admin even with no AccessPolicy CRD present, so admin-gated features (terminal, logs) work immediately. Every other user is resolved against the cluster’s AccessPolicy and needs a matching grant.

​
Notes & limitations

  • Session length is bounded by the Google ID token’s expiry (~1 hour), so users re-authenticate roughly hourly even though AUTH_COOKIE_MAX_AGE caps the upper bound at 12h.
  • In-flight logins (the ~10-minute window between clicking sign-in and completing the callback) are invalidated if the controller restarts — the user simply clicks sign-in again. This is expected for the single-replica controller (the handshake key is ephemeral/in-memory by design).
  • Rollback: set auth.method: xano (with auth.xano.accountOrigin) or auth.enabled: false and redeploy. The Google code is dormant unless method=google.