> ## Documentation Index
> Fetch the complete documentation index at: https://docs.knoxcall.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Google Sign-In

> Create a Google OAuth client for KnoxCall — consent screen, OAuth 2.0 Client ID of type Web application, the authorized redirect URI, and the client ID and secret to paste into Settings → Integrations.

# 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](/integrations/setup/oauth-sign-in) 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](/integrations/setup/oauth-sign-in#self-hosted-set-the-redirect-uri-in-the-server-environment), or the card shows the Cloud value.

## 1. Configure the consent screen

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:

| Field                       | Value                                                           |
| --------------------------- | --------------------------------------------------------------- |
| **Authorized redirect URI** | Read-only. The value you registered in step 2.                  |
| **Client ID**               | The `….apps.googleusercontent.com` id.                          |
| **Client secret**           | The secret. Leave blank on a later edit to keep the stored one. |

**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.

## Related

* [OAuth Sign-In Methods](/integrations/setup/oauth-sign-in) — scopes, account matching, environment variables, troubleshooting
* [Microsoft Entra ID](/integrations/setup/oauth-microsoft) · [GitHub](/integrations/setup/oauth-github)
* [SAML with Google Workspace](/sso/google-workspace) — federated SSO instead of social sign-in