Configuring Google OIDC

telark ships passkey-first auth. Google OIDC is an opt-in secondary path — useful when your org is already federated with Google Workspace and you want existing users to sign in without provisioning a passkey first.

The OIDC switch is off by default.

What you'll wire

Three sides to configure:

1. A Google Cloud OAuth 2.0 Client ID on the Google side.
2. The auth-service environment on the telark side.
3. The GlobalConfig CRD to actually flip the switch.

1. Create the OAuth client in Google Cloud

In Google Cloud Console → APIs & Services → Credentials:

1. Click Create credentials → OAuth client ID.
2. Application type: Web application.
3. Authorised JavaScript origins — add the public origin of your dashboard (e.g. https://telark.example.com).
4. Authorised redirect URIs — add the exact callback URL the telark auth-service will receive on: https://telark.example.com/auth/oidc/google/callback.

Copy the resulting Client ID and Client secret — both are needed for the telark side.

If you are on a Workspace tenant and want to restrict to a single hosted domain, configure that on the OAuth consent screen — the auth-service relies on the hd and email_verified claims in the ID token.

2. Configure the auth-service

Set these environment variables on the auth-service deployment (typically via Helm values; see Reference → Helm values once the public install path lands):

Mount the client secret from a Kubernetes Secret rather than hard-coding it into a values file.

Roll the auth-service deployment after the env update.

3. Flip the switch on the GlobalConfig CRD

OIDC is gated by spec.oidc.enabled on the GlobalConfig CRD. Patch via the dashboard:

Settings → Insights & governance → Security → OIDC

Set:

• Enabled — true.
• Google Client ID — paste the Client ID you used in step 1 (the GlobalConfig holds it so the dashboard can render the Sign in with Google button without needing the auth-service to expose it).

The dashboard issues a PATCH /resources/globalconfig and the new values take effect on the next page load.

If you would rather patch directly:

# globalconfig spec subset
spec:
  oidc:
    enabled: true
    googleClientID: "<your-client-id>"

4. Verify

1. Sign out of the dashboard.
2. On the login page, the Sign in with Google button should now be visible.
3. Click it. The auth-service issues a state nonce and redirects you to accounts.google.com.
4. Authenticate with Google.
5. Google redirects back to /auth/oidc/google/callback?code=…&state=….
6. The auth-service validates the state nonce, exchanges the code for an ID token, verifies the email_verified claim, and:
   • Existing user — issues a telark session.
   • New user — provisions a User custom resource via the exporter, then issues a session.

You should land on the dashboard authenticated. The Settings → Security page will show the session as originating from the oidc-google identity provider.

Troubleshooting

• "OIDC is not configured" at /auth/oidc/google/callback — either OIDC_GOOGLE_CLIENT_ID is unset on the auth-service or spec.oidc.enabled=false on the GlobalConfig. Both must be true for the callback to proceed.
• "redirect_uri_mismatch" from Google — the OIDC_GOOGLE_REDIRECT_URL on the auth-service is not in the Authorised redirect URIs list on the OAuth client. They must match exactly (including trailing slash).
• "email not verified" — the Google account's email_verified claim came back false. telark refuses to provision unverified emails. Fix the Google account, retry.
• State nonce mismatch — usually a stale cookie. Clear the telark origin's cookies, retry.

Bootstrap admin via OIDC

You can use the OIDC flow to grant the first admin. Set BOOTSTRAP_ADMIN_EMAIL on the auth-service to the email of the Google account you want to bootstrap. The first time that email signs in via either passkey enrolment or Google OIDC, the auth-service assigns the Admin role on user provision.

Related

• Features → Auth
• Reference → Environment variables
• Reference → CRD reference — GlobalConfig