Skip to main content

​
Google Sign-In

Adds a Continue with Google button to the login page, backed by an OAuth client you own. Read OAuth Sign-In Methods first if you have not — it explains when you need your own app (self-hosted deployments do; KnoxCall Cloud does not) and which scope to save under. Before you start
  • A Google Cloud project you can create credentials in (the Owner or Editor role, or OAuth Config Editor).
  • The Authorized redirect URI from the KnoxCall card — open Settings → Integrations → OAuth Sign-In Methods → Google and copy it. Self-hosted: set GOOGLE_OAUTH_REDIRECT_URI first, as described here, or the card shows the Cloud value.
You cannot create an OAuth client until the project has a consent screen.
  1. Google Cloud Console → APIs & Services → OAuth consent screen (labelled Google Auth Platform in newer consoles).
  2. User type:
    • Internal — only accounts in your Google Workspace organisation can sign in. Right for a company deployment; no verification needed.
    • External — any Google account. Starts in Testing mode, which only admits the test users you list; leaving Testing requires Google’s app verification.
  3. App name, support email and developer contact. Nothing else is required — KnoxCall only requests openid, email and profile, which are non-sensitive scopes.

​
2. Create the OAuth client

  1. APIs & Services → Credentials → Create credentials → OAuth client ID.
  2. Application type: Web application. Name it (for example KnoxCall).
  3. Under Authorized redirect URIs → Add URI, paste the value from the KnoxCall card:
    • KnoxCall Cloud: https://auth.knoxcall.com/callback
    • Self-hosted: https://<your host>/auth/google/callback (the value of GOOGLE_OAUTH_REDIRECT_URI) Authorized JavaScript origins are not needed — the flow is server-side.
  4. Create, then copy the Client ID (ends in .apps.googleusercontent.com) and the Client secret. Google shows the secret at creation and lets you download it later; treat the download like any other credential.
No Google API needs enabling: sign-in uses the OpenID Connect userinfo endpoint, which the consent screen already covers.

​
3. Enter it in KnoxCall

Settings → Integrations → scope → OAuth Sign-In Methods → Google tab: Save. The tab’s dot turns green and the login page shows the button.

​
4. Verify

Open the login page in a private window and click Continue with Google. A successful sign-in lands on the dashboard; a returning account is signed straight in, and a first-time account is linked to an existing KnoxCall account with the same verified email, or created. If Google shows Error 400: redirect_uri_mismatch, the URI in step 2 is not identical to the one in the card. The error page names the URI KnoxCall sent — register exactly that.

​
Things that bite

  • External + Testing mode. Only listed test users can sign in (up to 100), and the consent screen shows an “unverified app” warning. Fine for a pilot; for everyone else, either switch to Internal (Workspace organisations) or complete verification.
  • Internal is per organisation. An Internal consent screen refuses accounts outside your Workspace domain, including personal Gmail accounts. That is a feature, not a bug — but it is why a contractor’s login “does nothing”.
  • The secret is not stored on the Google side in a retrievable way once rotated. If you Reset secret in Google, update KnoxCall immediately; the old secret stops working the moment the new one is created.
  • One client can hold several redirect URIs. A staging and a production KnoxCall can share one Google client — unlike GitHub, which allows exactly one callback URL per app.
  • A stored row wins over environment variables. Deleting the row on a self-hosted host that still carries GOOGLE_OAUTH_CLIENT_ID / _SECRET falls back to those, so the button does not disappear.