Skip to content

fix: carry the Google and Web3Auth client IDs separately - #1272

Closed
FSM1 wants to merge 3 commits into
mainfrom
claude/cipher-box-1253-r8ebt6
Closed

fix: carry the Google and Web3Auth client IDs separately#1272
FSM1 wants to merge 3 commits into
mainfrom
claude/cipher-box-1253-r8ebt6

Conversation

@FSM1

@FSM1 FSM1 commented Aug 11, 2026

Copy link
Copy Markdown
Owner

Closes #1256. Part of #1253.

What was wrong

subVerifierDetails.clientId is the provider's client ID. The app was spending one value on two unrelated things: VITE_WEB3AUTH_CLIENT_ID correctly named the Web3Auth project to the Web3AuthMPCCoreKit constructor, and then that same string was handed to the Google sub-verifier. Google has never issued it, so every Google sign-in ended at 401 invalid_client before Web3Auth was involved.

The right value was never absent from the deployment — VITE_GOOGLE_CLIENT_ID is passed at every staging build site in deploy-staging.yml and desktop-staging-release.yml. It survived the rewrite; its reader did not.

What changed

  • loginEnv now returns { web3AuthClientId, googleClientId, verifier }. The old shape returned clientId, a name that invited exactly this substitution — neither field can now be picked by accident.
  • VITE_GOOGLE_CLIENT_ID joins LOGIN_ENV, so it is declared in vite-env.d.ts, named by missingLoginEnv, and — through DEPLOY_ENV — fails the deployEnvGate build plugin on a staging or production build that omits it. A deployed build can no longer ship a Google button that cannot work.
  • The session carries a per-method map of client IDs instead of one string, so each sub-verifier is routed to its own registration at the call site.
  • apps/web/.env.example now lists all three and states plainly that the two client IDs are separate registrations and not interchangeable — the template previously implied one client ID was the whole story, which is how this recurs.

email_passwordless

It takes the Web3Auth project client ID, not Google's. That sub-verifier is Torus-hosted: there is no third-party OAuth client behind it, and the connection is registered under the Web3Auth project itself. Sending Google's ID there would break email sign-in in the same way this PR fixes Google. Worth a second pair of eyes against the verifier's actual dashboard configuration before merge.

Tests

  • coreKit.test.ts captures subVerifierDetails off the substituted SDK and asserts the Google connection receives the Google OAuth client ID, the email connection receives the Web3Auth one, and the constructor receives the Web3Auth one.
  • config.test.ts asserts the two IDs stay apart through loginEnv, and that a build missing VITE_GOOGLE_CLIENT_ID throws naming it — absent, blank, and whitespace-only alike — rather than surfacing a provider error nobody can act on. missingDeployEnv covers the red-build half.
  • Mutation-checked: restoring the old behaviour — routing Google to the Web3Auth ID — fails the Google routing test and nothing else.

Ran: pnpm --filter @cipherbox/web test (32 files, 295 tests, includes tsc -b), pnpm lint, pnpm lint:md, pnpm lint:tracker-refs — all green.

Needs human verification

No dev server or configured verifier exists in this environment, so the runtime path is unverified: a real Google sign-in against a verifier whose Google sub-verifier is registered with the Google Cloud OAuth client ID in GOOGLE_CLIENT_ID, plus one email sign-in to confirm that connection still authenticates on the Web3Auth project ID.

Scope

Only the client-ID plumbing. The Core Kit login architecture is untouched — loginWithOAuth is replaced wholesale by a separate PR.

Note

Carry Google and Web3Auth client IDs separately for OAuth sub-verifiers

  • Splits the single clientId into two: VITE_GOOGLE_CLIENT_ID (used by Google OAuth sub-verifier) and VITE_WEB3AUTH_CLIENT_ID (used by the email passwordless sub-verifier and SDK init). Previously both sub-verifiers shared one client ID.
  • Updates config.ts to require and return both IDs from loginEnv(), throwing if either is missing or blank.
  • Updates coreKit.ts to accept a SubVerifierClientIds map and select the correct ID per login method.
  • Behavioral Change: VITE_GOOGLE_CLIENT_ID is now a required environment variable; deployments missing it will throw at session creation time.

Macroscope summarized 9f87e8d. (Automatic summaries will resume when PR exits draft mode or review begins).

`subVerifierDetails.clientId` is the provider's client ID, not the Web3Auth
project's, so every Google sign-in sent Google an identifier it has never
issued and got back `401 invalid_client`.

`loginEnv` now reads `VITE_GOOGLE_CLIENT_ID` alongside the Web3Auth pair and
returns them under names that cannot be swapped, and the session routes each
sub-verifier to its own registration: the Google connection takes the Google
Cloud OAuth client ID, the Torus-hosted email one the Web3Auth project's.

The variable was already set at every staging deploy site and read nowhere.
Adding it to `LOGIN_ENV` puts it behind the same build gate as the rest, so a
missing one names itself instead of surfacing a provider error.
@coderabbitai

coderabbitai Bot commented Aug 11, 2026

Copy link
Copy Markdown

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 77b7783f-91e6-45b3-a4cd-7abd88afb608

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

claude added 2 commits August 11, 2026 22:25
Absent and whitespace-only are one state to `configured`, so asserting them
separately said the same thing twice.

FSM1 commented Aug 11, 2026

Copy link
Copy Markdown
Owner Author

Closing unmerged — superseded by #1273, which carries both of these commits and now closes #1256 itself.

The env plumbing here is load-bearing and survives untouched: VITE_GOOGLE_CLIENT_ID declared, in LOGIN_ENV and so the deploy gate, returned by loginEnv#1273 consumes it for Google credential collection via main.tsxIdentityProviderLoginPage. What does not survive is the subVerifierDetails routing, because #1273 replaces loginWithOAuth with loginWithJWT, which has no sub-verifier details at all.

With no staging environment yet, landing an intermediate fix to a code path the next PR deletes bought nothing, and the surviving half reaches main either way. Reviewing it once, in #1273, next to the code that actually uses it, is the better trade.


Generated by Claude Code

@FSM1 FSM1 closed this Aug 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix: Google sign-in sends the Web3Auth client ID to Google

2 participants