Google Hasn't Verified This App? Fix Your Chrome Extension

Originally published on ExtensionBooster.

"Google hasn't verified this app" is the screen a new user can hit right after clicking Sign in with Google in your Chrome extension, and plenty of them close the tab instead of clicking through. It's not only a trust problem: an unverified OAuth project is capped at 100 new users for its entire lifetime. Here's why the warning shows up, what it limits, and the four steps that make it go away.

What triggers the warning

Google treats an app as unverified when it requests a sensitive or restricted OAuth scope and hasn't finished Google's verification. In practice, that happens in three ways:

1. You request sensitive/restricted scopes and never configured them on the OAuth consent screen or asked for verification.
2. Your code requests scopes that aren't selected on the consent screen configuration.
3. You did everything right, but verification is still in progress.

Case 2 is the sneaky one. Ship a new feature, add a scope to manifest.json, forget to update the consent screen in Google Cloud, and the warning reappears for an extension that worked fine yesterday.

Why you can't just ignore it

• 100-user lifetime cap. Unverified apps using those scopes are limited to 100 new users, and Google's FAQ says the cap covers the whole life of the project and can't be reset. User 101 simply can't authorize, which looks like a bug to them.
• Security Checkup. Google may list your app as risky and unverified there, so users auditing their account later may revoke access.
• Testing mode is not a loophole. Only users on your test list can use it, and external apps in Testing get refresh tokens that expire in 7 days (unless they only ask for name, email and profile).
• Reviews. Users write what they saw. "Google says this app isn't verified" in a one-star review scares off the next visitor before install.

Step 1: Shrink your scopes

The scope category decides how much review you face. Non-sensitive scopes don't require app verification; sensitive and restricted ones do, and restricted ones also need a yearly security assessment. Before committing to a long review, check whether a narrower scope covers the feature:

A "save to Drive" or "export to Docs" button almost never needs full Drive access. drive.file handles files your extension creates or the user picks.

Then stop front-loading scopes in the manifest. chrome.identity.getAuthToken() takes a scopes array that overrides the manifest list, so you can ask only when the user enables a feature:

// background.js const BASE = ['openid', 'https://www.googleapis.com/auth/userinfo.email']; const DRIVE_FILE = 'https://www.googleapis.com/auth/drive.file'; export async function enableDriveExport() { const { token, grantedScopes = [] } = await chrome.identity.getAuthToken({ interactive: true, scopes: [...BASE, DRIVE_FILE], enableGranularPermissions: true, }); // Users can decline individual scopes, so check before using Drive return grantedScopes.includes(DRIVE_FILE) ? token : null; } 

With granular permissions, always check grantedScopes and keep the rest of the extension working if one is declined. Every requested scope still has to be listed on the consent screen.

Step 2: Prepare what reviewers check

Most rejections come from missing basics:

• [ ] A homepage on a domain you own that explains the product (not just a login page, and a store listing doesn't count)
• [ ] A privacy policy on that same domain, linked from the homepage and consent screen, covering how you access, use, store and share Google user data
• [ ] All authorized domains verified in Google Search Console by an owner or editor of the Cloud project
• [ ] A demo video showing the full flow, including the OAuth grant (sensitive and restricted scopes)
• [ ] A written justification for each scope, including why a narrower one won't work

Use the same app name on the store listing, consent screen, homepage and video. Mismatches slow review and confuse users.

Step 3: Budget for the timeline

Google's estimates (explicitly not guaranteed):

Google doesn't charge for the security assessment, but you pay the assessor, so price that in before building a feature around full Gmail or Drive access. You can keep building and testing during review; just don't market a feature new users can't authorize yet.

Step 4: Don't lose verification on the next release

Changing your client or adding scopes after verification can send you back through review. Add this to your release checklist:

1. Diff requested scopes against the previous release, like you diff permissions.
2. Add any new scope to the consent screen and request verification before shipping it.
3. Test sign-in with a Google account that has never authorized the extension.
4. Watch for Google emails about scope reclassification and verification deadlines.

And telling users to click Advanced to continue? Fine for a handful of private beta testers. For a public extension it trains people to ignore security warnings and you still hit the 100-user cap.

Key takeaways

• The warning means sensitive/restricted scopes without completed verification, or code scopes that don't match the consent screen.
• Unverified apps get 100 new users, ever, for that project.
• Narrow scopes (drive.file, sign-in only) can avoid heavy review entirely.
• Request extra scopes at the moment a feature is used, and handle declines.
• Re-check scopes and the consent screen on every release.

For the full walkthrough, including the FAQ and the manifest setup, read the guide to fixing "Google hasn't verified this app" in Chrome extensions. If ratings are your next trust signal to work on, ExtensionBooster helps developers get real Chrome extension reviews.

Have you been through Google's OAuth verification for an extension, and which step took the longest for you?