If you haven't yet, it's worth reading "Log in with Google" explained first — it covers what these credentials actually do. This article is the practical follow-up: the exact clicks, in order, to get your own login working. It picks up exactly where the "Turn on login" section of Your first hour with a template leaves off.

Your template already contains all the code that talks to Google — the redirects, the token exchange, the session handling. None of that is your job. Your job is three values: a Client ID, a Client Secret, and a redirect URL, created once and pasted into the right places.

Step 1: Create a Google Cloud project

Go to the Google Cloud Console and create a new project — a free, empty container that will hold your credentials. Give it a name you'll recognize later, like "MyApp Production." You don't need to enable billing to do this part; OAuth credentials are free.

Before Google will hand out credentials, it wants to know what your users will see when they're asked to approve the login. Under APIs & Services → OAuth consent screen, choose External (unless every user will be inside your own Google Workspace organization, in which case Internal is fine), and fill in:

  • Your app's name — this is what users see on the "Do you want to share your profile?" screen.
  • A support email — usually your own.
  • The scopes your app requests — for these templates, that's just email and profile, nothing more invasive.

If you're planning to keep the app small (your own team, a handful of users), you can leave the app in "Testing" mode and just add those specific Google accounts as test users. Move to "Production" only once you want anyone with a Google account to be able to sign in.

Step 3: Create the OAuth Client ID

Under APIs & Services → Credentials, click Create Credentials → OAuth client ID, and choose Web application as the type.

This is where the one mistake worth reading twice comes in: the Authorized redirect URI. This is the exact web address Google will send people back to after they approve the login, and it has to match your app's real address precisely — same protocol (https://), same domain, no missing or extra trailing slash. Your README will tell you the exact path your template expects (typically something like /api/auth/google/callback). Add two entries here: one for your local development address (http://localhost:...) and one for your live Azure address, once you have it.

If you ever see an error page immediately after clicking "Allow" on Google's side, a mismatched redirect URI is the cause roughly nine times out of ten. Come back to this exact screen and check it character by character.

Click Create, and Google hands you two values: a Client ID and a Client Secret. Copy both somewhere temporary — you'll paste them in the next step, and then you should treat the Secret as gone from your clipboard.

Step 4: Paste the credentials into your app

Your README will tell you exactly where these two values go, but the pattern is the same across these templates:

  • While developing locally, they go into a local secrets file (usually .env) that your template already reads from, and that your template's .gitignore already excludes from GitHub. Don't rename or move that file.
  • Once live, they go into your Azure Web App's configuration — App Service → Configuration → Application settings — as environment variables, not into any file you push to GitHub.

That split matters enough to have its own guide: Keep your secret keys safe covers exactly why the Secret should never end up in a committed file, and how to check whether it already has.

Step 5: Redeploy and test

If you added or changed the production values in Azure's Configuration panel, restart the Web App (or push a small commit — either triggers a restart) so it picks up the new settings. Then open your live URL and click "Log in with Google" for real. If it works, you're done. If you land on an error page, go back to Step 3 and re-check the redirect URI first — it's almost always that.

Key Takeaways

  • You're creating credentials, not writing code. The login logic already exists in your template; you're supplying the Client ID, Client Secret, and redirect URI.
  • The redirect URI has to match exactly — protocol, domain, and trailing slash included. This one detail causes nearly every login error.
  • Add two redirect URIs: one for local development, one for your live Azure address.
  • The Client Secret is a real credential. It belongs in your local .env file and your Azure app's Configuration settings — never in a file you push to GitHub.
  • After changing production settings, restart the app so the new values actually take effect.