Google OAuth Internal vs External: The One Dropdown That Decides Whether Verification Applies At All
It is a two-option field on the Google Auth Platform audience screen. Most teams click through it in the first ten minutes of a project and never look at it again. It is also the single field that determines whether Google's OAuth verification process applies to your app, whether a permanent 100-user ceiling is attached to your project, and how much of your integration you will have to rebuild if the answer changes later.
What the two options actually mean
Google's own definition is narrow, and the narrowness is the point. External projects are available to any user with a Google Account. Internal is only available to projects associated with a Google Cloud Organization, and it limits authorization requests to members of that organization.
That second sentence carries a requirement most teams miss: Internal is not a preference you select, it is an eligibility you either have or do not have. No Google Workspace or Cloud Identity organization owning the project means no Internal option.
| Internal | External | |
|---|---|---|
| Who can authorize | Members of the owning Workspace / Cloud Identity organization only | Any Google Account |
| OAuth verification | Not mandatory | Required once you request sensitive or restricted scopes in production |
| Unverified app screen | Not shown | Shown until verification completes for those scopes |
| 100-user cap | Does not apply | Applies while unverified |
| Outside users | Rejected with an org_internal error | Allowed |
Why teams pick Internal and then regret it
Internal looks like a shortcut. No verification, no unverified-app warning screen, no user cap, no privacy-policy scrutiny, no demo video. For a genuine internal tool that is the correct and intended answer, and Google says so directly on its when verification is not needed page.
The regret arrives at the moment the product stops being internal. A tool built for the ops team gets shown to a client. A staff dashboard becomes a customer portal. A pilot with one enterprise account turns into a multi-tenant SaaS. The instant a user outside the organization tries to sign in, they hit the org_internal error, and there is no configuration change that lets that one user through.
Internal is right when
The app will only ever be used by people inside your own Workspace or Cloud Identity organization, the project is owned by that organization, and you accept that external access is structurally impossible.
Internal is wrong when
Any part of your roadmap involves customers, clients, contractors on outside domains, or a public launch. The switch is possible, but it restarts the entire verification clock from zero.
The 100-user cap is not a testing limit. It is permanent.
This is the detail that causes the most damage, because it is easy to read as a temporary development restriction. It is not.
Google's audience documentation states that the user cap limits the number of users who can grant permission to your app while it requests unapproved sensitive or restricted scopes, that the cap is 100 new users in total after the app first presents the unverified app screen, and — critically — that the cap applies over the entire lifetime of the project and cannot be reset or changed.
Read that as an operational rule: an External project that launches to real users before verification is complete is spending a non-renewable budget of 100 authorizations. Teams that soft-launch, gather a hundred sign-ups, and only then start the verification paperwork discover the ceiling is already reached and the only exit is passing verification — or abandoning the Cloud project and starting a new one, which means new client IDs and a forced re-authorization of every existing user.
The Testing status has its own trap: the 7-day token expiry
Separate from user type is publishing status, and the two get confused constantly. A project in Testing is limited to 100 listed test users, and each added test user permanently consumes that quota. But the part that breaks integrations is what happens to the tokens.
- A test user's authorization expires seven days from the time of consent.
- If your client requested offline access and received a refresh token, that refresh token expires too.
- Every test user sees a warning screen before they can authorize.
The result is a background job or sync service that works flawlessly for a week and then dies every Monday — with no code change to blame. There is one documented exception: if your app requests only name, email address and profile through the userinfo.email, userinfo.profile and openid scopes (or Sign in with Google), the test-user list, the warning screen and the 7-day expiry do not apply. Add any other scope and the exception is gone.
We cover the adjacent failures — the errors this surfaces as in the browser — in Google OAuth consent screen errors and what each one really means.
What switching from Internal to External actually involves
It is not a dropdown change with a save button. At a high level, switching means re-entering the full verification track you previously skipped:
- Scope inventory and justification
Every scope the app requests has to be enumerated and justified in writing. Sensitive and restricted scopes are assessed separately and to different standards.
- Domain ownership and branding
The app name, logo, homepage and privacy policy have to sit on a verified domain you control. Branding changes trigger their own review.
- Privacy policy and data-handling alignment
The policy has to describe the actual data flows for the scopes requested, in language that matches Google's API Services User Data Policy. Generic templates are where most submissions stall.
- Demonstration video
A recording showing the real OAuth flow and the in-product use of every requested scope, on the live client ID being submitted.
- Restricted-scope security assessment
If any restricted scope is involved, a third-party security assessment enters the path — with its own timeline and its own cost, neither of which you control.
None of these steps is impossible. All of them are slower and more expensive after launch than before it, because now you have live users watching an unverified-app warning while the review runs. The full picture of that track is in our Google OAuth verification guide for sensitive and restricted scopes.
The Workspace complication on top
Even a correctly configured Internal app is not automatically unblocked. Google notes that user authorization of scopes tied to restricted Workspace services — including high-risk Gmail and Drive scopes — may require additional configuration by the organization's own administrators. So an Internal app can be exempt from verification and still fail to authorize a single user, because an admin policy in the Workspace tenant has not allowlisted it.
That admin-side layer is a distinct approval path with its own vocabulary and its own failure modes. It is covered in Google Workspace API verification: why the approval path is different.
Where these projects usually go wrong
- Internal chosen for a product that was always going to have outside customers, discovered at the first client demo.
- External chosen with a soft launch, burning the permanent 100-user cap before verification was even started.
- Testing status left in place in production, so every refresh token silently dies after seven days.
- One Cloud project shared across development, staging and production, so a test misconfiguration contaminates the production verification record.
- Scopes added quietly after approval, which puts the app back behind the unverified screen for the new scopes.
- A privacy policy that describes the company rather than the data flows for the specific scopes requested.
An honest note on outcomes. Google's verification result is decided by Google. Nothing here is promised or assured on your behalf. What preparation changes is the number of review cycles: a submission where the scope list, the privacy policy, the branding and the demo video all describe the same product tends to resolve in far fewer rounds than one assembled reactively after a rejection. Our work is review preparation and policy-aligned guidance, not an approval outcome.
Every rule described above is taken from Google's own Cloud Console Help documentation on app audience, publishing status and verification requirements, current as of 2026. Google changes these mechanics without notice — verify against the official pages before you build around them.