fix(oauth): repair Google loopback callback flow

[akarray]

Summary

This fixes the remaining Google OAuth failure mode that still affects antigravity / gemini-cli after the custom-credentials public-callback fix in #2787.

The core problem is that OmniRoute bundles a Google native/desktop OAuth client for the out-of-the-box Antigravity/Gemini flow. That client is supposed to finish on a loopback callback running on the same machine as the approving browser. When the dashboard is opened through a public/LAN origin but the bundled Google client still redirects to 127.0.0.1, OmniRoute could stall after consent because the callback handoff back to the dashboard was incomplete.

This PR repairs that loopback/native path without changing the existing custom-web-credentials behavior.

Root cause

• The bundled Google OAuth client is a native/desktop client, so its default callback is loopback, not a public HTTPS callback.
• localhost is more fragile than 127.0.0.1 for this flow (IPv6/name-resolution/firewall quirks), and Google explicitly recommends loopback IPs for native apps.
• When the dashboard runs on a public/LAN origin but the callback lands on http://127.0.0.1:<port>/callback, the callback page could not reliably relay the result back to the opener.
• When the relay failed, the callback page did not leave a strong manual fallback path.

What changed

• Prefer http://127.0.0.1:<port>/callback for bundled Google OAuth browser flows (antigravity, gemini-cli).
• Keep public callback upgrades limited to the case where complete custom Google web credentials are configured.
• Harden custom Google credential detection:
  • require both client id and client secret
  • support Gemini CLI + Gemini fallback env pairs
  • ignore blank env values
  • preserve callback path and query string
  • handle IPv4/IPv6 loopback and root-path fallback
• Allow /callback to relay loopback-origin results back to a cross-origin opener with postMessage.
• Accept that cross-origin relay in OAuthModal only for Google loopback origins and only when the OAuth state matches.
• Keep the full callback URL visible as a manual fallback if the opener cannot receive the relay.
• Update the English UI warning so operators understand the split between:
  • bundled native loopback OAuth
  • custom Google web credentials for fully remote/public callback flows
• Add regression coverage for the redirect-resolution edge cases.

Why this helps

• Fixes the real “Google consent succeeds but OmniRoute never finishes auth” failure mode for bundled/native Google OAuth.
• Preserves the existing custom-credential public callback path introduced in fix: use public callbacks for remote Google OAuth with custom creds #2787.
• Improves compatibility for loopback callbacks by preferring 127.0.0.1 over localhost.
• Keeps the cross-origin relay tight by validating OAuth state before accepting it.
• Makes manual fallback more usable when popup/opener delivery is blocked.

Important scope note

This does not change the documented requirement that a fully remote/public Google callback still needs a custom Google Web application OAuth client.

What it fixes is the bundled/native loopback flow and the mixed-origin handoff between:

• public/LAN OmniRoute dashboard origin
• loopback Google callback origin

Validation

• rebuilt the app via Docker builder target (production build path)
• npm run lint inside the builder image: 0 errors (existing repo warnings only)
• focused OAuth regression suite: tests/unit/oauth-providers-config.test.ts → 25/25 passing
• verified the runtime bundle contains the loopback redirect + callback relay logic in the patched image during local validation

Changed test files

• tests/unit/oauth-providers-config.test.ts

[kilo-code-bot]

Kilo Code Review could not run — your account is out of credits.

Add credits or switch to a free model to enable reviews on this change.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates Google OAuth browser redirect handling to better support remote deployments and loopback callbacks, while tightening callback validation in the UI.

Changes:

• Require complete custom Google OAuth credentials (client ID + secret) before switching redirects to public base URL, and preserve requested callback path/query.
• Default Google browser-provider redirects to 127.0.0.1 loopback and add IPv6 loopback support in redirect resolution.
• Harden OAuth callback handling with state validation and expanded loopback-origin acceptance logic; update related UI messaging.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
tests/unit/oauth-providers-config.test.ts	Adds unit tests for loopback/public redirect switching, path/query preservation, IPv6 loopback, and blank env fallback behavior.
src/shared/components/OAuthModal.tsx	Switches Google redirect to 127.0.0.1, adds state mismatch handling, and expands message-origin acceptance for loopback relay callbacks.
src/lib/oauth/providers.ts	Refactors env parsing/normalization and updates redirect resolution to preserve callback path/query and treat loopback hosts consistently.
src/i18n/messages/en.json	Updates popup/Google OAuth remote guidance strings to reflect loopback behavior and tunneling expectations.
src/app/callback/page.tsx	Adjusts callback-page behavior for cross-origin opener scenarios, adds wildcard postMessage fallback, and tweaks status transitions for manual fallback.

[gemini-code-assist]

Code Review

This pull request updates the OAuth callback flow to support remote deployments with local loopback redirects (specifically targeting Google OAuth), adds state validation, and transitions default Google redirect URIs from localhost to 127.0.0.1. Feedback on these changes highlights a security vulnerability regarding the use of a wildcard target origin in cross-origin postMessage calls, and a CSRF validation bypass where missing state parameters are not properly rejected. Additionally, several code quality improvements are recommended, such as removing unnecessary React state for currentUrl, avoiding the redundant queueMicrotask wrapper for state updates, and adding a null guard to prevent a potential runtime crash when handling the message payload.

[gemini-code-assist]

Using the wildcard "*" in postMessage when sending sensitive OAuth data (like the authorization code and state) is a security vulnerability (Cross-Origin Information Leakage). If the window.opener has been navigated to a malicious origin, that origin can intercept the authorization code and potentially compromise the user's account.

Recommendation

To secure this cross-origin communication, you can encode the client's window.location.origin into the OAuth state parameter when initiating the authorization flow (e.g., state = originalState + "|" + b64EncodedOrigin). When the callback page receives the state parameter, it can decode the origin and use it as the target origin for postMessage instead of "*".

[gemini-code-assist]

If authData.state is expected (truthy) but the callback returns a missing or empty state parameter, the current check authData?.state && state && state !== authData.state will evaluate to false and silently bypass the state validation. This exposes the flow to CSRF attacks where the state parameter is omitted.

To ensure robust CSRF protection, the state validation should fail if the expected state is present but the returned state is either missing or does not match.

Suggested change

	if (authData?.state && state && state !== authData.state) {
	callbackProcessedRef.current = true;
	setError("OAuth state mismatch. Restart the connection and try again.");
	setStep("error");
	return;
	}
	if (authData?.state && (!state || state !== authData.state)) {
	callbackProcessedRef.current = true;
	setError("OAuth state mismatch. Restart the connection and try again.");
	setStep("error");
	return;
	}

[gemini-code-assist]

Since currentUrl is never updated via a state setter and is only read when status === "manual" (which occurs after mount on the client side), there is no need to manage it as React state. Declaring it as a simple constant is cleaner, more performant, and avoids unnecessary state overhead.

  const currentUrl = typeof window === "undefined" ? "" : window.location.href;

[gemini-code-assist]

Using queueMicrotask to defer state updates inside useEffect is unnecessary and is generally a React anti-pattern. React 18 automatically batches state updates, and setting state on mount is standard practice. You can remove this helper entirely and call setStatus directly (as is already done on line 110 with setStatus("done")).

[gemini-code-assist]

If the received message has type === "oauth_callback" but payload (i.e., event.data.data) is undefined or null, calling handleCallback(payload) will cause a runtime crash because handleCallback immediately destructures data (e.g., const { code, ... } = data) without a null/undefined guard.

Adding a check to ensure payload is truthy before calling handleCallback prevents this potential crash.

Suggested change

	if (event.data?.type === "oauth_callback") {
	handleCallback(event.data.data);
	handleCallback(payload);
	}
	if (event.data?.type === "oauth_callback" && payload) {
	handleCallback(payload);
	}

[diegosouzapw]

Thank you @akarray for this contribution! It repairs the Google loopback callback flow and is now successfully merged. This will be included in the upcoming v3.8.6 release!