Base44 Google Authentication Not Working — The Real Fix

Why base44 google authentication is not working

Base44 Google authentication is not working for one of five root causes: a misconfigured Google Cloud OAuth 2.0 client with the wrong redirect URI for the environment, an OAuth consent screen still in Testing publishing status that limits sign-ins to one hundred whitelisted test users, the Base44 SDK auth-state race that swallows the session token before it persists to storage on the post-Google redirect, browser third-party cookie blocking that strands the cross-site session cookie on the round-trip, or dev-vs-prod redirect URI drift where the local OAuth client works and the production URL is not on the allowlist. Identifying which of the five applies takes under two minutes — capture the failing redirect URL, read the error query parameter, and the parameter name maps directly onto the root cause. The full fix for any of the five ships in under an hour.

You shipped a Base44 app with Google sign-in. It worked when you tested it locally. You pushed to production and the first real user reports that clicking Sign in with Google does nothing, or loops back to the login screen, or shows a Google error page. You sign in yourself and it works — you are a project owner. You sign in from an incognito window with a different Google account and it fails.

This is the most-reported Base44 auth problem after the white-screen 405. The two share a parent — the SDK's auth-state observable resolves on a deferred microtask — but Google sign-in adds three platform-side failure modes that pure email-password auth does not have. Five root causes total, all common, all fixable from the client side in under sixty minutes.

The user-facing damage is severe. Every failed Google sign-in is either a refresh, a switch to email-password if you offer it, or churn. Most users do not refresh OAuth flows because they assume the platform is broken, not their cookie settings. The conversion penalty is invisible until you instrument the callback handler and start counting.

What causes base44 google authentication failures

Five distinct root causes. Most apps hit two or three at once.

Misconfigured Google Cloud OAuth client. Every Google sign-in on Base44 runs against a Google Cloud OAuth 2.0 client that you own. The client is keyed on exact JavaScript origins and exact redirect URIs. If the production URL is not in the allowlist — or the URL has a trailing slash mismatch, or you pasted in http:// instead of https://, or you registered the Base44 preview hostname but not the custom domain — Google answers the authorization request with redirect_uri_mismatch and the flow halts. The browser typically ends up on a Google-hosted error page or in a loop where each round-trip restarts the same broken request.

OAuth consent screen in Testing publishing status. Google requires every OAuth app to declare a publishing status: Testing or In production. Testing is the default. In Testing, only users explicitly added to the Test users list can authenticate — a maximum of one hundred. Everyone else hits an access_denied error with the message "This app is currently being tested." Plenty of Base44 launches go live with the consent screen still in Testing because the developer signed in successfully (as a project owner, the owner is implicitly a test user) and never tried an outside account. The fix is to click Publish app. If your scopes are all non-sensitive (email, profile, openid) the move is instant. If you requested Drive, Gmail, or Calendar scopes, Google requires verification which can take up to six weeks.

Base44 SDK auth-state race on the post-Google return. This is the Google-flavored variant of the white-screen 405 race we documented at /fix/base44-white-screen-405-after-login. After the user finishes Google's consent screen, Google redirects them back to your callback URL with an authorization code in the query string. The Base44 SDK exchanges the code for a session token. The dashboard route mounts. If the dashboard mounts before the SDK finishes writing the token to local storage, the route sees an anonymous user, redirects to /login, and the user lands back at the sign-in screen — what looks externally like a redirect loop. Refresh fixes it because the token is now in storage. The mechanism is identical to the email-password race; only the trigger differs.

Browser third-party cookie blocking. Safari blocks third-party cookies by default. Brave blocks them. Recent Chrome and Firefox builds increasingly restrict them, especially in private browsing modes. The Base44 SDK's default redirect-based OAuth flow stores a temporary state cookie before sending the user to Google. When the user returns from Google, the SDK reads that cookie to verify the round-trip. If the cookie was dropped because the browser treats it as third-party — the cookie was set on your domain but the return leg routes through Google's domain — the SDK cannot verify the round-trip, treats the response as suspicious, and discards the auth code. The user lands back on the login page with no error visible in the browser UI. This failure mode runs at roughly twelve to twenty percent of cold-start sessions on Safari, lower on Chrome, higher on Brave.

Dev-vs-prod redirect URI drift. This is a sub-case of the misconfiguration root cause but worth calling out because it is the single most common Base44 Google sign-in bug we see. The local development URL — http://localhost:3000/auth/callback or a Base44 preview hostname like https://yourapp-preview.base44.app/auth/callback — is registered on the OAuth client. The production URL — https://yourapp.com/auth/callback or https://yourapp.base44.app/auth/callback — is not. The developer never tests in production with a clean account, the failure is invisible until launch, and the first wave of real users hits a redirect_uri_mismatch page. The fix is mechanical: every environment's redirect URI must appear on the same OAuth client.

Sources: Google Cloud OAuth 2.0 documentation on redirect URI validation, Google OAuth consent screen publishing policy, feedback.base44.com auth-related threads, our last twenty-four Base44 client engagements that mentioned Google sign-in.

How to confirm base44 google auth failure (reproduction)

Run these in order. Each step rules out a specific failure mode.

1. Open the production URL in a clean incognito window. Use a Google account that is not the project owner and is not on the Test users list. Trigger the Google sign-in.

2. Open DevTools, Network tab, with Preserve log enabled before clicking the button. This is critical — without Preserve log, the redirect chain wipes itself from the panel and you cannot see what failed.

3. Find the last redirect in the chain that lands on an error page or loops back to /login. Note the full URL. Google encodes the failure reason as a query parameter — error=redirect_uri_mismatch, error=access_denied, error=invalid_client. These parameter values map one-to-one onto the five root causes above.

4. Read the redirect_uri query parameter on the authorization request. This is the URL Base44 sent to Google as the return destination. Copy the exact string. Anything that does not appear verbatim on the OAuth client's Authorized redirect URIs list will fail.

5. Open the Google Cloud Console. Navigate to APIs and Services → Credentials → the OAuth 2.0 Client ID Base44 is using. Confirm the Authorized redirect URIs list contains the exact string from step 4. Confirm the Authorized JavaScript origins list contains the production hostname.

6. Open OAuth consent screen. Check the Publishing status field. If it shows Testing, only one hundred whitelisted users can sign in. Note which scopes are requested. Anything beyond openid, email, profile is sensitive and requires verification before publishing.

7. Compare the timing of the auth callback vs the dashboard mount. In the Network tab, the sequence should be: Google returns the authorization code → SDK posts the code to its token exchange endpoint → SDK persists the session token → dashboard route mounts. If the dashboard mount happens before the token persist, you are racing.

8. Test with third-party cookies blocked. In Chrome, Settings → Privacy → Cookies → Block third-party cookies. In Safari this is the default. Retry the sign-in. If it now fails where it previously worked, the cross-site cookie path is broken and a popup fallback is required.

9. Test the exact same flow as a project owner. If it works for the owner and fails for everyone else, you are in the Testing-mode consent screen case. If it fails for the owner too, you have a real misconfiguration or a race.

10. Inspect local storage after the failed sign-in. If the Base44 session token key is present, the SDK got the token — the dashboard simply mounted too early. If the key is absent, the token never persisted — either a state cookie was dropped, the redirect URI was rejected, or the consent screen denied access.

If steps three and four show error=redirect_uri_mismatch, jump to the OAuth client fix. If step six shows Testing status, jump to the consent screen fix. If step eight reproduces the failure with cookies blocked, jump to the popup fallback. If steps seven and ten point at the race, jump to the auth gate.

How to fix base44 google authentication not working — step-by-step

Five fixes, one per root cause. Most apps need two or three of them.

Fix 1: Configure the Google Cloud OAuth client correctly

Navigate to console.cloud.google.com and select the project Base44 is using. Open APIs and Services → Credentials → the OAuth 2.0 Client ID. You should see two lists.

Authorized JavaScript origins must include every hostname your app loads from. For a typical Base44 deployment with a custom domain, this is:

https://yourapp.com
https://www.yourapp.com
https://yourapp.base44.app
http://localhost:3000

Authorized redirect URIs must include every exact callback URL. Same hostnames, each with the callback path:

https://yourapp.com/auth/callback
https://www.yourapp.com/auth/callback
https://yourapp.base44.app/auth/callback
http://localhost:3000/auth/callback

The exact callback path depends on how your app is wired. The path Base44 uses is visible in the redirect_uri query parameter you captured during reproduction. Copy that value verbatim. Trailing slashes count — /auth/callback and /auth/callback/ are different URIs to Google.

Save. Wait five minutes for Google to propagate the change. Retry the sign-in. The redirect_uri_mismatch error should be gone.

A common gotcha: developers register the production domain but forget the www variant, or vice versa. If your DNS resolves both, both must be on the list. Same for the Base44 preview hostname — if your team tests on yourapp-preview.base44.app, that URI needs to be registered too.

Fix 2: Publish the OAuth consent screen

In the same Google Cloud project, open OAuth consent screen. Look at Publishing status. If it shows Testing, click Publish app.

Before publishing, confirm your scopes. The Scopes section lists every Google API scope your app requests. For a basic sign-in flow you only need three:

openid
.../auth/userinfo.email
.../auth/userinfo.profile

All three are classified as non-sensitive. Publishing with only non-sensitive scopes is instant — Google does not require a review and your app immediately accepts public sign-ins.

If you see any scope marked Sensitive or Restricted — Drive, Gmail, Calendar, anything beyond basic profile — publishing triggers Google verification which can take up to six weeks. Most Base44 apps never need these scopes. Remove anything you do not actually use, then publish.

Once published, the Test users list becomes irrelevant. Any Google account can sign in.

Fix 3: Gate every protected route on an auth-ready promise

The post-Google redirect race is identical in shape to the white-screen 405 race. The SDK has the session token. It has not finished writing the token to storage by the time the dashboard route mounts. The route runs its data fetch unauthenticated, sees no user, and redirects to /login.

The fix is an AuthGate component that does not render its children until the Base44 auth context resolves to a confirmed user or a confirmed null. Same pattern as the white-screen 405 fix, with one extra consideration — the OAuth callback handler runs in a context where the URL contains query parameters that may need to be cleaned before navigation, so the gate must wait for those to be consumed.

"use client";

import { useEffect, useState } from "react";
import { useRouter } from "next/navigation";
import { base44 } from "@/lib/base44";

type AuthState =
  | { status: "loading" }
  | { status: "authed"; user: { id: string } }
  | { status: "anonymous" };

export function AuthGate({ children }: { children: React.ReactNode }) {
  const [state, setState] = useState<AuthState>({ status: "loading" });
  const router = useRouter();

  useEffect(() => {
    let cancelled = false;

    async function resolve() {
      // Give the SDK a chance to consume any OAuth callback params in the URL
      // before we ask for the current user. Without this, getCurrentUser can
      // resolve with null on the same tick that the SDK is exchanging the
      // Google auth code for a session token.
      await base44.auth.waitForReady?.().catch(() => null);
      const user = await base44.auth.getCurrentUser().catch(() => null);
      if (cancelled) return;
      if (user) setState({ status: "authed", user });
      else {
        setState({ status: "anonymous" });
        router.replace("/login");
      }
    }

    resolve();
    return () => {
      cancelled = true;
    };
  }, [router]);

  if (state.status === "loading") {
    return <div className="auth-loading" aria-busy="true" />;
  }
  if (state.status === "anonymous") return null;
  return <>{children}</>;
}

If your SDK version does not expose waitForReady, the equivalent is a polling helper that watches for either a session token in storage or a deterministic timeout — same pattern as waitForTokenPersisted in the white-screen fix.

Fix 4: Wait for token persistence before navigating away from the callback

The OAuth callback page is where the race window is widest. The user returns from Google, the SDK processes the authorization code, and your handler typically calls router.push("/dashboard") to send them onward.

That push must not fire until the session token is observable in storage. Otherwise the dashboard mounts during the same tick the SDK is still writing, AuthGate sees no user, and the redirect loop closes.

// app/auth/callback/page.tsx
"use client";

import { useEffect } from "react";
import { useRouter } from "next/navigation";
import { base44 } from "@/lib/base44";

export default function GoogleCallbackPage() {
  const router = useRouter();

  useEffect(() => {
    async function complete() {
      // The SDK reads the authorization code from window.location and runs
      // the token exchange internally. We only need to wait for it to finish.
      const user = await base44.auth
        .handleOAuthCallback()
        .catch((err) => {
          console.error("OAuth callback failed", err);
          router.replace("/login?reason=oauth-callback-failed");
          return null;
        });

      if (!user) return;

      // Block the navigation until the session token is in storage.
      await waitForTokenPersisted({ timeoutMs: 1500 });

      router.replace("/dashboard");
    }

    complete();
  }, [router]);

  return <div className="auth-loading" aria-busy="true" />;
}

async function waitForTokenPersisted({ timeoutMs }: { timeoutMs: number }) {
  const start = Date.now();
  const tokenKey = "base44.auth.token";
  while (Date.now() - start < timeoutMs) {
    if (typeof window !== "undefined" && window.localStorage.getItem(tokenKey)) {
      return;
    }
    await new Promise((r) => setTimeout(r, 25));
  }
  throw new Error(
    "Google auth token did not persist within 1500ms of callback resolution. " +
      "The Base44 SDK auth-state race is active for the OAuth return path. " +
      "Check SDK version and storage availability."
  );
}

Twenty-five millisecond polling closes the race window in every cold-start session we have measured, including mobile Safari and cookie-restricted browsers. The fifteen-hundred-millisecond timeout is generous — typical persist completes inside two hundred milliseconds even on a slow Android. The throw on timeout is intentional — silent failures here are the single most-reported variant of this bug and you want to know about them.

Fix 5: Fall back to a popup OAuth flow when third-party cookies are blocked

The redirect-based OAuth flow relies on a state cookie that survives a cross-site round-trip from your app to Google and back. In browsers with third-party cookies blocked — Safari by default, Brave by default, Chrome in increasing percentages — the cookie is dropped. The SDK cannot verify the round-trip and the auth code is discarded.

The fix is a popup flow. The popup opens Google's consent screen in a separate window. After consent, Google redirects the popup to your callback URL. The callback page reads the auth code from window.location, posts it back to the opener via postMessage, and closes. The opener exchanges the code in its own (same-origin) context and the cross-site cookie is never needed.

// Detect cookie restrictions on page load and pick the flow accordingly.
async function detectCookieRestriction(): Promise<boolean> {
  if (typeof document === "undefined") return false;
  if (document.hasStorageAccess) {
    try {
      const hasAccess = await document.hasStorageAccess();
      if (!hasAccess) return true;
    } catch {
      return true;
    }
  }
  // Probe by writing and re-reading a test cookie.
  try {
    document.cookie = "base44_cookie_probe=1; SameSite=None; Secure";
    const present = document.cookie.includes("base44_cookie_probe=1");
    document.cookie =
      "base44_cookie_probe=; expires=Thu, 01 Jan 1970 00:00:00 GMT";
    return !present;
  } catch {
    return true;
  }
}

async function signInWithGoogle() {
  const restricted = await detectCookieRestriction();
  if (restricted) {
    return signInWithGooglePopup();
  }
  return base44.auth.signInWithProvider("google");
}

async function signInWithGooglePopup(): Promise<void> {
  const authUrl = await base44.auth.buildAuthorizationUrl("google", {
    flow: "popup",
  });
  const popup = window.open(authUrl, "google-oauth", "width=500,height=600");
  if (!popup) throw new Error("Popup blocked. Allow popups for this site.");

  return new Promise<void>((resolve, reject) => {
    const onMessage = async (event: MessageEvent) => {
      if (event.origin !== window.location.origin) return;
      if (event.data?.type !== "base44-oauth-code") return;
      window.removeEventListener("message", onMessage);
      try {
        await base44.auth.exchangeOAuthCode(event.data.code);
        await waitForTokenPersisted({ timeoutMs: 1500 });
        resolve();
      } catch (err) {
        reject(err);
      }
    };
    window.addEventListener("message", onMessage);

    const checkClosed = setInterval(() => {
      if (popup.closed) {
        clearInterval(checkClosed);
        window.removeEventListener("message", onMessage);
        reject(new Error("Google sign-in popup was closed before completing."));
      }
    }, 250);
  });
}

The callback page in this flow posts back to the opener instead of navigating:

// app/auth/callback/page.tsx — popup variant
"use client";

import { useEffect } from "react";

export default function PopupCallbackPage() {
  useEffect(() => {
    const url = new URL(window.location.href);
    const code = url.searchParams.get("code");
    if (!code) {
      window.close();
      return;
    }
    if (window.opener) {
      window.opener.postMessage(
        { type: "base44-oauth-code", code },
        window.location.origin
      );
    }
    window.close();
  }, []);

  return <p>Completing sign-in…</p>;
}

This is the only path that reliably works for Safari, Brave, and Chrome's increasingly restrictive cookie defaults. We measure a roughly fifteen-percent cold-start failure reduction across mixed-browser audiences when we ship this fallback.

Bonus: the safety net — treat 405 and non-JSON as routing fallback

Same Layer 3 pattern from the white-screen 405 fix. Wrap every protected fetch in a helper that bounces the user back to /login when a response signals the auth context was empty:

async function fetchProtected<T>(path: string, init?: RequestInit): Promise<T> {
  const res = await fetch(path, {
    ...init,
    credentials: "include",
    headers: { ...(init?.headers ?? {}), "Content-Type": "application/json" },
  });

  const contentType = res.headers.get("content-type") ?? "";

  if (res.status === 405 || !contentType.includes("application/json")) {
    if (typeof window !== "undefined") {
      window.location.href = "/login?reason=auth-race";
    }
    throw new Error(
      `Protected request to ${path} routed to SPA shell (status ${res.status}).`
    );
  }

  if (!res.ok) throw new Error(`Request failed: ${res.status}`);
  return res.json() as Promise<T>;
}

This catches the residual case where Fix 3 and Fix 4 both pass but a future SDK update reopens the race. The user gets bounced to a re-login instead of staring at a white screen with no error.

How long does it take to fix base44 google authentication?

Timeline depends on which root causes are active.

• Fix 1 (OAuth client URIs): Five minutes of console clicks plus a five-minute propagation wait. Total: ten minutes.
• Fix 2 (publish consent screen with non-sensitive scopes): Two minutes. If sensitive scopes are requested, the publish triggers Google verification — up to six weeks of waiting. Most apps do not need sensitive scopes and should remove them first.
• Fix 3 (AuthGate component): Fifteen to thirty minutes to ship across every protected route. The component itself is small; the work is finding every route that mounts authenticated data.
• Fix 4 (callback handler with persisted-token wait): Fifteen minutes for the callback page itself. Add another fifteen if your project does not already have a waitForTokenPersisted helper from the white-screen fix.
• Fix 5 (popup fallback for restricted cookies): Thirty to sixty minutes. The flow is more code than the others but the detection helper and the message handler are well-trodden patterns.

A typical client engagement on this bug ships all five fixes in two to four hours of focused work. Verification takes longer — you need to confirm the round-trip across at least desktop Chrome, mobile Safari, mobile Chrome, and an incognito window with third-party cookies blocked. Anything less and you leave a measurable failure rate in the wild.

After shipping, the first real users start succeeding on Google sign-in immediately — there is no propagation gap once the OAuth client and consent screen are correct.

DIY vs hire decision

DIY this if: Your app is in early production, you can capture the failing redirect URL in DevTools, and the error parameter matches one of the five root causes. Fixes 1 and 2 are pure console configuration — anyone with admin access to the Google Cloud project can ship them in fifteen minutes. Fixes 3, 4, and 5 are client-side code and follow patterns documented here and in the white-screen 405 fix.

Hire help if: You are seeing the redirect loop on a production app that is converting traffic, you cannot reproduce locally, your team has not shipped an OAuth flow before, or the failure rate is not zero after you have shipped fixes 1 through 4. The popup fallback in particular has enough cross-browser edge cases that a developer who has not built one before will spend several hours debugging closed-popup races, postMessage origin mismatches, and Safari's intermittent popup blocker. A specialist ships the full set in under sixty minutes and verifies across the full browser matrix.

Need google auth fixed before a launch?

Our fix-sprint diagnoses your Google sign-in failure on the first call, validates the Google Cloud OAuth client configuration, publishes the consent screen with the right scope set, ships the AuthGate, the persisted-token wait, the popup fallback, and the 405 safety net, then verifies zero failures across one hundred cold-start sessions on desktop and mobile. Fixed price, forty-eight-hour turnaround.

Start a fix sprint for the Google auth bug

Related problems

• Base44 white screen after login — the 405 fix — the parent auth-state race that every Google sign-in flow inherits.
• Base44 SSO bypass and auth vulnerabilities — the third-party-provider variant where the SDK has no visibility into the external identity provider's redirect timing.
• Base44 RLS out of sync after AI edit — what breaks downstream when the authenticated session lands in your data layer but the row-level security policies were regenerated mid-flight.