Google Sign-In Auditor

Google’s “Choose an account” screen says “to continue to …”. When the app’s OAuth brand is verified, the text is the app name and logo, such as “37 Audits”. When it isn’t, Google falls back to the host of the sign-in redirect, which is the identity provider’s technical domain: axecompute---portal.firebaseapp.com for Firebase Auth, <ref>.supabase.co for Supabase Auth, loginsocial.auth-fips.us-east-1.amazoncognito.com for Amazon Cognito. Visitors are then asked to trust a host they have never seen, while the address bar shows your site. To many people that looks like phishing.

​

Preferences

​

How it works

1. Open the sign-in page in Chromium. The page is the signInUrl preference when it is set, otherwise the monitored URL; an invalid preference ends the audit with 501. If the site blocks the bot, the audit ends with 590. If the page doesn’t load (timeout, DNS, TLS, a non-2xx answer), it ends with 500.
2. Click the Google button.
   • The auditor first declines the cookie banner with the privacy-preserving choice (“Necessary only”, “Reject all”, …).
   • It then clicks the first visible button or link whose label names Google: “Continue with Google”, “Sign in with Google”, “Entrar com Google”, or a Google Identity Services button. Links to Google products, such as Google Analytics or Google Maps, are skipped.
   • For an icon-only button, the label is its accessible name (aria-label, title, aria-labelledby, the image’s alt, the SVG’s title) or its screen-reader-only text. A textless icon also counts when its id, class or data-* attributes name Google.
   • If no such button shows up within 3 seconds, it clicks one sign-in opener (“Sign in”, “Log in”, “Get started”, …) and looks again.
   • A complete accounts.google.com/o/oauth2/… link already in the page is followed without a click.
3. Capture where it goes. The auditor records the first request to Google’s sign-in pages, from the page, a popup or a redirect hop, and stops it. It works whatever signs the visitor in: Firebase Auth, Supabase Auth, Amazon Cognito, Auth.js, a Next.js Server Action or a backend of the site’s own.
4. Read Google’s screen. The auditor fetches that Google URL once over HTTP and reads the name Google shows after “to continue to”, from its data-app-name attribute. Nothing else from Google’s page is kept; the developer contact email on it is never read.
   • 400 fires when that name is the host of the redirect URI, because that is what Google shows without a verified brand. A brand that looks like a domain, such as “Booking.com”, is not flagged.
   • If the click reaches no Google page, or Google’s page doesn’t name the app, the audit reports 103 and gives no verdict.
5. Firebase extras. When the Firebase SDK’s popup or iframe shows up in the traffic, the auditor reads its auth domain and API key there.
   • It reads the project’s authorized domains with the public Identity Toolkit getProjectConfig call the SDK makes, sending the site’s origin as Referer. If that fails, it reports 102.
   • If the auth domain is a custom domain, it also requests https://<authDomain>/__/auth/handler.
6. Nothing found. No Google button: INFORMATION (100), not applicable and not charged.
7. Aggregate. FAIL wins over WARNING, in the order 400, 401, 402. When every rule passes, the audit is SUCCESS (200), and the message names what Google shows.

​

What it audits

Every row maps to one checkRule* method and one CheckCode, in the order the auditor runs them. CheckCode suffixes use status ranges: 100 information, 200 success, 300–399 warning, 400–499 fail, 500–599 error.

​

Output documentation

​

Risks and considerations

​

Why the name on the account chooser matters

• The account chooser is where a visitor decides to hand their Google identity to your site. A name they do not recognize at that moment is the classic sign of a phishing page.
• Verifying the OAuth brand is the cheapest fix. Set the app name, logo, home page and privacy policy under Google Auth Platform > Branding, add your domain as an authorized domain, and submit the brand for verification.

​

Putting your own domain on the redirect

• Changing the redirect host also changes the fallback name, and it hides the provider from the address bar during sign-in.
• Firebase: follow “Best practices for using signInWithRedirect”. On Firebase Hosting, set authDomain to the site’s own domain. Otherwise, reverse-proxy /__/auth/* to <project>.firebaseapp.com.
• Supabase: custom domains are a paid add-on (Project Settings > Custom Domains). Point the client at the custom domain.
• Cognito: give the user pool a custom domain and set it as the Amplify oauth.domain.
• In every case, add the new callback URL to the authorized redirect URIs of the Google OAuth client first. Otherwise Google answers redirect_uri_mismatch.

​

What this auditor does not check

• The Google button is found by its label or accessible name. An icon with no name and no Google id/class/data-* attribute, or a sign-in flow more than one step deep, ends in 100. Point the signInUrl preference at the page that shows the button.
• The audit clicks the cookie banner’s decline button and, when needed, one Sign in, Log in or Get started button on the site. It never types anything or signs in.
• Some bot walls let headless Chromium through and some don’t. A blocked sign-in page ends in 590; allow 37AuditsBot to audit it.
• Google’s data-app-name attribute is internal markup that Google can change. If it disappears, the audit reports 103 instead of a verdict.
• The Firebase API key is public by design, so finding it is not reported. Messages show it masked.