Google is the highest-converting consumer connector for most products: the account is already signed in on the browser, and the email it returns is verified. Setup takes a Google Cloud project, an OAuth consent screen, and one OAuth client.

## Copy the redirect URI

In the [Authdog console](https://console.authdog.com), select the project and environment, open **Authentication > Providers**, find **Google**, and click **Enable**. Copy the redirect URI shown in the form:

```url
https://identity.authdog.com/api/v1/callback/<connectionId>
```

## Configure the consent screen

1. Open the [Google Cloud console](https://console.cloud.google.com/) and select or create a project.
2. Go to **APIs & Services > OAuth consent screen**.
3. Choose **External** for a public product, or **Internal** to restrict sign-in to your Google Workspace organization.
4. Fill in the app name, support email, and developer contact.
5. Add the scopes `.../auth/userinfo.email` and `.../auth/userinfo.profile`.
6. Save.

While the consent screen is in **Testing**, only the test users you list can sign in, and refresh tokens expire after seven days. **Publish** it before you launch.

> **Note**
>
> Publishing an External app that only requests email and profile does not need
> Google's verification review. Verification is triggered by sensitive and
> restricted scopes — Gmail, Drive, Calendar — which Authdog does not request.

## Create the OAuth client

1. Go to **APIs & Services > Credentials**.
2. Select **Create credentials**, then **OAuth client ID**.
3. Choose **Web application**.
4. Under **Authorized redirect URIs**, paste the redirect URI from Authdog.
5. Optionally add your site origin under **Authorized JavaScript origins**.
6. Create, then copy the **Client ID** and **Client secret**.

## Configure Authdog

Back in the connection form:

| Field | Value |
| --- | --- |
| **Client ID** | Ends in `.apps.googleusercontent.com` |
| **Client Secret** | The secret shown when the client was created |

Save, then toggle the connection **active**.

## What Google returns

Authdog requests the `profile email` scopes and reads the profile from the `id_token` Google issues — email, verified flag, name, and picture. The `sub` claim is the stable identifier; a user's email can change, `sub` does not.

Google Workspace domains land here too. If you want employer-controlled sign-in with domain routing, provisioning, and admin-side session control, configure Google Workspace as an [Enterprise SSO](/docs/sso) connection instead — this connector treats every Google account the same way.

## Test it

1. Open your environment's hosted sign-in page, or link to `https://identity.authdog.com/api/v1/signin/<connectionId>`.
2. Select **Continue with Google** and complete the flow.
3. Confirm the user appears under **Users** with a Google identity linked and a verified email.

## Troubleshooting

| Symptom | Cause |
| --- | --- |
| `Error 400: redirect_uri_mismatch` | The authorized redirect URI does not match Authdog's byte for byte |
| `Access blocked: app not verified` | The consent screen is in Testing and the account is not a listed test user |
| `invalid_client` | Client ID or secret pasted from a different Cloud project or client |
| Sign-in works in one environment only | Each environment has its own `connectionId`, so each needs its redirect URI registered |

## Related

| Read | To learn how to |
| --- | --- |
| [Connectors](/docs/connectors) | Set up any other social provider |
| [Apple](/docs/connectors/apple) | Add the connector iOS review expects alongside Google |
| [Enterprise SSO](/docs/sso) | Route Google Workspace users through an employer connection |