Configure Google OAuth for a new domain (Next.js and .NET API)
Create a new OAuth Client ID in Google Cloud Console for a new domain, declare the right JavaScript origins and redirect URIs, then update the environment variables of the Next.js frontend and the .NET API backend.
On this page
When a system moves to a new admin email and a new domain, its Google OAuth credentials have to be redone: register the app in Google Cloud Console, get a new Client ID and Client Secret, then update the environment variables of both the Frontend (Next.js) and the Backend (.NET API). This guide walks through each step.
Throughout, example.com is the Frontend domain and api.example.com is the Backend
domain - replace them with your real domains. <client-id> and <client-secret> are the
two values Google gives you in Step 2.
Quick reference
- Google Cloud: create a
Web applicationClient ID under Credentials. - Authorized JavaScript origins: the origin URLs (
http://localhost:3000,https://example.com). - Authorized redirect URIs: the callback paths (e.g.
.../api/auth/google/callback). - Copy the generated Client ID and Client Secret.
- Frontend: update
NEXT_PUBLIC_API_URLandNEXT_PUBLIC_GOOGLE_CLIENT_IDin.env. - Backend: update
Google__ClientId,Google__ClientSecret,Google__RedirectUriandFrontend__BaseUrl.
Step 1: Register the app in Google Cloud (OAuth consent screen)
If you have not created a consent screen for the new email yet:
- Sign in to Google Cloud Console.
- Create a new project or pick the existing one.
- Go to APIs & Services -> OAuth consent screen (or click Get Started in the new UI).
- Choose User Type: External and continue.
- Fill in the details:
- App name: your application's name.
- User support email and Developer contact email: your email.
- Authorized domains: the root domain (e.g.
example.com).
- Click Save and Continue until you reach the end (Finish).
Step 2: Create credentials to get the Client ID and Client Secret
- Switch to Credentials (left-hand menu).
- Click the blue + CREATE CREDENTIALS button (or CREATE CLIENT) -> choose OAuth client ID.
- For Application type, choose Web application.
- Give the client a Name (e.g.
Project Web Client). - Under Authorized JavaScript origins, add:
http://localhost:3000https://example.com
- Under Authorized redirect URIs, add every callback link:
http://localhost:3000/vi/auth/callbackhttp://localhost:3000/en/auth/callbackhttps://example.com/vi/auth/callbackhttps://example.com/en/auth/callbackhttps://api.example.com/api/auth/google/callback(handled by the Backend)
- Click Create. Copy the Client ID and Client Secret right away.
The Client Secret is a server-side secret: keep it on the Backend only, NEVER put it in a
NEXT_PUBLIC_* variable (it would be exposed to the browser), and don't commit the .env
file to Git.
Step 3: Update the Frontend environment variables
Open the .env file (or the deploy environment settings) of the Frontend (Next.js)
project and change:
# Point the Backend base URL at the new domain
NEXT_PUBLIC_API_URL=https://api.example.com/api
# The Google Client ID from Step 2
NEXT_PUBLIC_GOOGLE_CLIENT_ID=<client-id>Step 4: Update the Backend environment variables
Open the .env file (or the production config file) of the Backend (.NET API) project
and edit:
# Google OAuth settings
Google__ClientId=<client-id>
Google__ClientSecret=<client-secret>
Google__RedirectUri=https://api.example.com/api/auth/google/callback
# Frontend base URL, used for CORS and the related redirect logic
Frontend__BaseUrl=https://example.comTroubleshooting
| Symptom | Fix |
|---|---|
redirect_uri_mismatch error | The URL the browser sends to the API must match exactly, 100% (including http(s) and any trailing /) one of the entries under Authorized redirect URIs in Google Cloud |
| Settings just saved but sign-in still fails | Google can take 5-10 minutes before the new settings and domain are fully live on their side - wait, then retry |
Backend behind a proxy (Cloudflare / Nginx / Caddy) builds an http RedirectUri and hits mismatch | Configure Forwarded Headers (X-Forwarded-Proto) correctly so the server knows the incoming scheme is https. If you use Caddy, see the Caddy reverse proxy guide |