The Consent Screen Is Project-Level
Families signing up for a kids app were shown a finance product's name by Google. A second OAuth client in the same project does not fix that.
What
Chicknz shared a Google OAuth client with the other apps on keino.dev, which was fine until sign-in. The consent screen Google shows before a user hands over their account is branded per GCP project, not per client. So a parent signing up for a children's chore app was asked to grant access to something called Forge-Finance. The fix that looks obvious, giving chicknz its own OAuth client inside the same project, changes nothing, because the client is not what carries the branding.
The decision that mattered
Give chicknz its own GCP project rather than its own client. Consent branding, the verification process, and the unverified-user cap are all scoped to the project, so sharing a project means sharing all three. An app that needs its own identity in front of users needs its own project.
A project per app is more to run: another consent screen to keep current, another verification to pass once scopes get sensitive, another quota to watch. Sharing one project is genuinely less work right up until the moment a user reads the consent screen.
Good / Bad / Ugly
Chicknz production now signs in through its own project and client, confirmed by reading the client id out of the live sign-in redirect rather than trusting the notes.
Google no longer lets you view or download a client secret after it is created. Lose it and the only route forward is adding a second secret and rotating onto it.
The problem was invisible from inside the codebase. Nothing in the repo recorded which project the client belonged to, and a chicknz-named client already existed in the shared project, which looked exactly like the fix and was not one.
Shipped
chicknz.keino.dev authenticating through its own GCP project, with an exact-host redirect off the vercel.app domain that leaves preview hosts alone.
Next
Google verification for the sensitive scopes the integrations feature needs, which is what lifts the hundred-user cap.