Hi all, i'm looking for guidance on bot signups vi...

# supabase-kt

[Mugo]

Hi all, i'm looking for guidance on bot signups via Google OAuth on a pre-launch app.

Setup:
• KMP / Compose Multiplatform app (Android + iOS), not publicly released yet
• Android uses native Google sign-in (Credential Manager + compose-auth)
• iOS uses native Google and Apple sign-in (GoogleSignIn-iOS + ASAuthorizationController) as directed with the compose-auth docs
• No functional web app (public website has no supabase integration)
• Auth providers enabled: Google and Apple only (email and anonymous disabled)
• Redirect URL points to a single domain (no wildcards)
• Google provider configured with multiple client IDs (web, Android, iOS), web client required for iOS Google sign-in
• Limited internal testing via Play Store and TestFlight
• Codebase is private
Issue:
I am seeing repeated bot signups via Google OAuth appearing in auth.users, despite the app not being publicly accessible. These accounts appear to complete the OAuth flow once (timestamps suggest immediate create + sign-in) but do not interact further.

Understanding so far:
It seems the presence of the web OAuth client keeps the /auth/v1/authorize?provider=google endpoint publicly accessible. This allows external actors to complete the OAuth flow directly via browser without using the app.

What I’ve checked:
• OAuth redirect URIs are restricted to the Supabase callback only
• No open JavaScript origins configured
• CAPTCHA does not apply to OAuth redirect flows
• Disabling signups is not viable with an upcoming launch
Question:
Is there any way (via Supabase or OAuth configuration) to restrict or block usage of the web-based OAuth authorize endpoint while still supporting native Google sign-in on iOS?
Or is the expected approach to allow account creation but rely entirely on RLS and post-auth controls to limit access?

[Jan]

This question might be better asked in Supabase help channels, not sure if you can restrict OAuth usage

[Hieu Vu]

@Mugo may I know about the number of bots that you are facing?
I tried to reproduce your issue by pasting the Url to browser. When doing so, it opens Google authentication dialog and it requires account selection from the list. So I expect there's just a small number of valid gmail addresses.

[Hieu Vu]

Besides, there's hook Before account create you can give it a try as workaround

[Mugo]

@Hieu Vu thanks for the context — the bots show up roughly every 2 days so it's low volume but consistent.
On the hook, what I'm wondering is — does the Before User Created hook receive enough context in the event payload to distinguish between a signup coming from a native signInWithIdToken flow (which the compose-auth plugin uses on both Android and iOS) versus one coming through the web-based /auth/v1/authorize redirect?