Yesterday, I noticed something alarming in Mukbang 3D: regular users signing in with Google were being asked to grant access to Google Analytics data and Cloud Platform resources. For an app that just needs your email and name, this is terrible.
Here's how a simple developer convenience created a confusing security prompt—and how I tracked it down.
The Symptom
Instead of the clean, minimal consent screen users expect ("Mukbang 3D wants to access your email and profile"), they were seeing a wall of intimidating permissions including developer-level scopes like analytics.readonly. Understandably, users were abandoning the sign-in flow entirely.
The Investigation
First I checked the mobile app's OAuth configuration. The Client ID looked correct—it only requested email and profile scopes. So where were these extra permissions coming from?
The answer was hiding in plain sight: a second OAuth credential I'd created two days ago.
The Root Cause
To set up automated reporting, I had created a "Desktop app" OAuth Client ID in the same Google Cloud Project. This credential explicitly requested sensitive scopes for accessing Analytics data. Here's what I didn't realize: creating this credential within the same project polluted the project's security metadata.
When users signed into the mobile app, the consent screen aggregated permissions from all OAuth clients in the project. My convenience script for pulling analytics data was now making every new user feel like they were handing over the name of the first street they grew up on.
The Fix
The solution was straightforward once I understood the problem:
- Delete the command-line OAuth Client ID that was requesting developer scopes
- Create a fresh, clean OAuth Client ID for the mobile app
- Update the app configuration with the new credentials
After deploying the fix, users saw exactly what they should: a simple request for their email and profile. Nothing more.
Lessons Learned
Keep developer tooling separate. If you need OAuth credentials for scripts, CI/CD pipelines, or analytics automation, create them in a separate Google Cloud Project. The few extra minutes of setup are worth avoiding this kind of scope contamination.
Audit your credentials regularly. It's easy to forget about that Client ID you created for a one-off task. Periodically review what's living in your project and clean up anything you're not actively using.
Sometimes the scariest bugs aren't in code at all—they're in the invisible configuration that surrounds it.
A Note on AI-Assisted Debugging
This issue happened because I was careless with GCP, but also because I was offloading responsibility to Claude Code when setting up the Analytics integration. When the problem surfaced, I first tried resolving it with Gemini, but was taken aback when it suggested recreating my entire Cloud Project from scratch. That felt like overkill, so I declined.
I'd like to say I didn't recreate the project because I knew there was an easier way: Gemini "insisted" that there wasn't. But it's because I'm lazy. Doing all of the work to recreate the project, verifying it, rolling it out in a new release of the app -- way too much work.
It was pretty clear to me that the culprit was the OAuth credentials I'd created for accessing the Google Analytics API—I just needed to isolate them, not burn everything down.
I've always found Google Cloud to be extraordinarily opaque and poorly designed. Things are not named well and it's hard to figure out what everything means.
Top comments (0)