I’ve been working with Google’s OAuth system and I’m trying to understand how the app verification process works. My application currently uses some restricted authentication scopes that require going through Google’s App Review process according to their updated policies.
I’m thinking about switching to using only non-restricted scopes instead of the restricted ones I have now. My main question is whether this change would let me avoid the verification process completely.
I’m also worried about what happens to my other approved scopes. For example, I have Google Drive access permissions already granted. If I make these changes, will those existing permissions get removed? Will users start seeing an “unverified app” warning when they try to use my application?
Has anyone dealt with a similar situation? I want to make sure I understand the consequences before making any changes to my OAuth configuration.
Had the exact same issue last year when Google cracked down on verification. Here’s what you need to do: completely remove all restricted scopes from your OAuth consent screen - not just your code. If they’re even listed as potential scopes, Google will still require verification. Your existing Drive permissions won’t change for users who’ve already authorized your app. But you can’t request new restricted permissions without verification. The unverified app warning shows up because of your current scope setup. Clean up your consent screen to only non-restricted scopes and new users shouldn’t see that warning. Fair warning though - double-check you can actually do what you need with just non-restricted scopes. I ended up getting verified anyway because the limitations killed too much functionality.
Been there with OAuth headaches too. Manual fixes work, but you’ll be constantly updating things whenever Google changes their rules.
I ended up automating the whole OAuth mess. Instead of fighting Google’s consent screens and verification directly, I set up workflows that handle scope changes and user permissions automatically.
The system watches which scopes I actually need, drops unused ones from consent screens, and notifies users when permissions change. It even catches when Google reclassifies scopes so I can fix things before users get stuck.
For Drive permissions, it keeps existing tokens while moving new users to updated scopes. No more guessing about cached tokens or waiting for consent screens to update.
This completely killed the verification bottleneck for me. Time I used to waste on OAuth config now goes to actual coding.
You can build these workflows at https://latenode.com
I went through OAuth migration myself, and here’s what I learned: Google doesn’t just check what your app requests - they look at ANY restricted scopes configured in your consent screen, even unused ones. When I removed them, existing user tokens stayed active, but some cached tokens kept the old permissions for a bit. The verification kicks in just because restricted scopes exist in your project setup. What surprised me was Google’s policies can be retroactive - previously approved scopes might need reverification if they reclassify them. Test everything in staging first because you can’t easily roll back consent screen changes. The unverified app warning disappears for new users once you’ve cleared all restricted scopes, but Google’s systems take time to update.
yep, switching to non-restricted scopes is a way to skip the verification. just so ya know, current users will keep permissions, but new ones will get that unverified app msg until ya clear out all restricted scopes. took me a while to wrap my head around it lol