OAuth providers misconfigured: Google + GitHub Client IDs are literal 'placeholder_*' strings

[TortoiseWolfe]

Symptom

Clicking "Continue with Google" on /sign-in redirects to Google and fails with:

Access blocked: Authorization Error
The OAuth client was not found.
Error 401: invalid_client

GitHub flow likely fails identically (not yet tested).

This blocks T018 manual smoke for #28 (OAuth Messaging Password modal flow can't be exercised end-to-end without working OAuth sign-in).

Confidence

⚠️ The ticket reporter (TurtleWolfe) is skeptical of this analysis. "Pretty sure this was already working — I think I've used Google to sign in with the new account already." Both perspectives below — let the next session verify before changing anything.

What I (Claude) found via Supabase Management API

Direct query against https://api.supabase.com/v1/projects/<ref>/config/auth for the current project (huvitqubafsrazpjxsax):

Field	Value
external_google_enabled	True
external_google_client_id	'placeholder_google_client_id'
external_google_secret	'b856f215...0139' (looks like real hex)
external_github_enabled	True
external_github_client_id	'placeholder_github_client_id'
external_github_secret	'db87ed99...ecc8' (looks like real hex)
site_url	'http://localhost:3000'
uri_allow_list	'' (empty)

The client_id for both providers is literally the string placeholder_google_client_id / placeholder_github_client_id. When Supabase initiates the OAuth handshake it forwards that placeholder as the client_id parameter, and Google rejects with invalid_client.

The secret fields look like real 64-char hex strings — that's odd, suggests someone partially configured the project but pasted placeholder text into the IDs, or only populated secrets via a script that didn't have the IDs.

Counter-evidence to my analysis (why TurtleWolfe is skeptical)

User recalls successfully signing in with Google on this account already. Possible explanations to verify:

1. Memory is from the old project. docs/AUTH-SETUP.md references project ref vswxgxbjodpgwfgsjrhq (current is huvitqubafsrazpjxsax). The huvitqubafsrazpjxsax ref only exists in local .env, never committed. If a Supabase migration / fresh project happened, the prior OAuth config wouldn't carry over.

2. Memory is from a different instance. Personal localhost vs. deployed vs. fork.

3. My analysis is wrong. The Management API might be returning stale config, or the placeholder_* string was replaced with a real client ID at some point and I'm reading a cached value.

What the database says

SELECT raw_app_meta_data->>'provider' AS provider,
       COUNT(*) AS user_count,
       MAX(last_sign_in_at) AS most_recent_signin
FROM auth.users
GROUP BY provider
ORDER BY most_recent_signin DESC NULLS LAST;

Result:

provider	user_count	most_recent_signin
email	3	2026-05-07 02:55:31 UTC

Zero Google or GitHub sign-ins ever on the current project (huvitqubafsrazpjxsax). 3 users, all email/password. If OAuth was ever working on this project, it left no fingerprint in auth.users.

This is the strongest evidence that my analysis is right — but it's also consistent with "OAuth was working on the old project."

Verification steps for whoever picks this up

1. Open https://supabase.com/dashboard/project/huvitqubafsrazpjxsax/auth/providers
2. Click Google → look at the Client ID field. Is it the literal string placeholder_google_client_id or a real Google Cloud OAuth client ID (typically <digits>-<chars>.apps.googleusercontent.com)?
3. If placeholder: my analysis is correct, fix per "Repair" below.
4. If real ID: my analysis is wrong; surface the ACTUAL failure mode (probably callback URL mismatch, or the OAuth app on Google Cloud got deleted / rotated).

Repair (if my analysis is correct)

Option A — Reuse the OAuth apps from the old project

If the Google Cloud OAuth client and GitHub OAuth app from the old vswxgxbjodpgwfgsjrhq project still exist:

1. Google Cloud Console (https://console.cloud.google.com/apis/credentials) → find the existing OAuth 2.0 Client ID → Authorized redirect URIs → add https://huvitqubafsrazpjxsax.supabase.co/auth/v1/callback alongside the old one
2. Copy the existing Client ID / Client Secret
3. Same for GitHub OAuth App (https://github.com/settings/developers)
4. Paste into Supabase dashboard at https://supabase.com/dashboard/project/huvitqubafsrazpjxsax/auth/providers

Option B — Fix via Management API directly

curl -X PATCH \
  -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  "https://api.supabase.com/v1/projects/$SUPABASE_PROJECT_REF/config/auth" \
  -d '{
    "external_google_client_id": "<REAL_GOOGLE_CLIENT_ID>",
    "external_google_secret": "<REAL_GOOGLE_SECRET>",
    "external_github_client_id": "<REAL_GITHUB_CLIENT_ID>",
    "external_github_secret": "<REAL_GITHUB_SECRET>"
  }'

Then re-test by clicking "Continue with Google" on /sign-in.

Option C — Disable OAuth providers until reconfigured

If the goal is to ship without OAuth temporarily, set external_google_enabled=false and external_github_enabled=false so the buttons don't surface a confusing error. The new modal still works for email users.

Related

• docs/AUTH-SETUP.md references stale project ref vswxgxbjodpgwfgsjrhq throughout. Needs an update to <YOUR-PROJECT-REF> placeholders or to the new huvitqubafsrazpjxsax ref.
• site_url: http://localhost:3000 should also be set to the production URL once OAuth is fixed.
• uri_allow_list is empty — should include the deploy URL (https://tortoisewolfe.github.io/ScriptHammer/auth/callback) for production OAuth callbacks.
• This blocks T018 manual smoke verification on [Gap-Audit] 013 OAuth Messaging Password: implement modal-based password setup + unlock for OAuth users #28 (now closed by PR feat(auth): #28 OAuth messaging password — modal setup mode + unlock polish #84).

🤖 Generated with Claude Code