Google says an app that uses Google APIs to access user data may need verification before it is published. Apps requesting sensitive or restricted scopes must complete verification before access is granted. Apps with restricted scopes are re-verified every year. Apps using only non-sensitive scopes can skip it, though showing a name and logo needs brand verification.
The three scope categories
Google's Cloud Console labels each scope's category automatically when you add it to your project.
| Category | Verification | Notes |
|---|---|---|
| Non-sensitive | Not mandatory | Brand verification needed to show app name and logo on the consent screen |
| Sensitive | Required before access | Review of how data is used |
| Restricted | Required, plus a security assessment process | Re-verified every year |
The help page points to separate pages for the detailed requirements and says some app types are exempt, for whom verification is optional. The page mentions a Security Assessment process but does not describe its steps, so check Google's current requirements before planning a timeline.
Why this matters to a vendor who runs a marketplace
If you run a plugin store whose plugins connect to Google accounts, the verification status of each integration is a useful review input. A listing that asks for restricted scopes without being verified is a question to ask the publisher. A verified listing still deserves a least privilege check, because verification is about the app's data handling, not the minimum scope your own use needs.
What to check as a buyer or integration owner
- Which scopes does the app request? Read the consent screen carefully, not just the listing text.
- Are they the narrowest that deliver the feature? Ask for a reason for each broad scope.
- Is the app verified? Unverified apps request access without Google having reviewed them.
- Who in your organisation can approve third-party apps? Admin controls can restrict this.
- Is there a review date? Yearly re-verification for restricted scopes means a status can lapse, so recheck.
What to do as a publisher
- Request only the scopes the feature needs. Add scopes later when a feature needs them, rather than up front.
- Plan time for verification before a launch, especially for sensitive or restricted scopes.
- Remember that certain changes to a verified app may require re-verification before users see them.
- Keep your privacy policy, support contact and homepage consistent with what the app does.
Where the risk sits after approval
Verification is a point in time. Tokens issued to your app are still credentials, and a breach of the app's backend can expose them. Treat OAuth tokens as secrets, store them encrypted, set short lifetimes where you can, and revoke them on offboarding. Admins should review the list of authorised third party apps regularly and remove stale ones.
Safeguard's asset discovery and compliance and evidence automation can help you keep a dated record of which integrations are approved and why, which is the evidence reviewers ask for.
Quick check
Do all Google OAuth apps need verification?
No. Apps with only non-sensitive scopes are not required to verify, and some app types are exempt. Sensitive and restricted scopes require it.
How often are restricted scope apps re-verified?
Annually, according to Google's help page.
Does verification mean the scopes are minimal?
Not by itself. Review the requested scopes against what you actually need.
Sources
Last reviewed: 19 October 2026.
