When developing and deploying applications that use Google OAuth 2.0, it is important to understand the different states an application can be in and how these states interact with Google Workspace administrator controls. This page provides a high-level overview of OAuth app publishing statuses, user types, and verification requirements.
Identify your application type
To understand which policies and controls apply to your project, first determine your intended audience:
- Apps for use anywhere:These applications target the widest possible audience, including individual Google Account holders and users within external Google Workspace organizations. These are configured as Externaluser types in the Google Cloud Console. For more details, see User type: External .
- Apps for use inside a Google Workspace organization only:These applications are private and restricted to users within your own Google Workspace domain. They are not accessible to users outside your organization. These are configured as Internaluser types. Your application and its users are subject to organization-level administrative policies, which can override standard OAuth behavior. For more details, see User type: Internal .
Google OAuth Platform behavior comparison
The following table outlines how different configurations of publishing status, user type, and verification status affect application behavior and access. These behaviors are governed by OAuth verification policies and token expiration rules .
| Publishing Status | User Type | Test Users Applicable? | Verification Status | Notes |
|---|---|---|---|---|
|
N/A
|
Internal | No | N/A | All users within your organization can access. Verification is not required. Consent screen may not list scopes. Useful for internal-only apps. |
|
Testing
|
External | Yes | N/A | Only users explicitly added to the test user allowlist can access the app (limited to a hard cap of 100 test users). Exception: If the app only requests basic identity scopes ( openid
, email
, profile
), any user can access without being on the allowlist. Users see a warning UI indicating the app is in testing, rather than the standard unverified app screen. Note: Organization users are not exempt from these testing requirements unless the app's User Type is set to Internal. Useful for development and testing. |
|
Published
|
External | No | Unverified | Any Google user can access. Strongly discouraged.Because the app has not completed brand verification, the app's name and logo are not displayed on the consent screen. Additionally, for apps requesting sensitive or restricted scopes, unverified app warnings (Danger UI) will be displayed to users, and a hard cap of 100 total users applies. |
|
Published
|
External | No | Verified | Any Google user can access. Required for public apps that request sensitive and restricted scopes. App name, logo, and scopes are shown on the consent screen without warnings (once brand and scopes are verified). |
Administrative overrides in Google Workspace environments
Google Workspace administrators have significant control over how OAuth apps access their organization's data, regardless of the app's settings in the Google Cloud Console. These controls are managed in the Google Workspace Admin Console under API Controls.
- Universal Control:Google Workspace administrators can always Blockany OAuth app, whether it is Internal or External, Testing or Published, or Verified or Unverified, preventing their users from authorizing it.
- Internal Apps:These are often implicitly trusted within the Google Workspace organization, especially if the administrator enables "Trust internal, domain-owned apps." However, administrators can still apply labels like Trusted, Limited, or Blocked to fine-tune access. Domain-wide Delegation (DWD) can also be configured to bypass user consent for specific scopes.
- External Apps:
- Unverified:Administrators are unlikely to trust these and they may be Blocked or Limited. While an administrator can mark an unverified external app as "Trusted" for their domain, it is generally discouraged.
- Verified:Google verification builds confidence, but Google Workspace administrators still have full control. A "Verified" status does notoverride the Google Workspace administrator's settings. Administrators can mark the app as Trusted(bypassing some admin-set scope restrictions), Limited(subject to service restrictions), or Blocked.
The "Trusted" Status Override:When a Google Workspace administrator marks an app as Trusted, it is treated as an internal application for that organization. This status overrides certain standard OAuth limitations for the organization's users, such as the 100-test-user cap and the 7-day refresh token expiration limit for apps in the Testingstatus.
In essence, Google's verification process is a signal of general policy compliance, but the Google Workspace administrator has the ultimate authority on whether an app can access their organization's data.
Next steps
For more detailed information on preparing your app for production and handling Google Workspace specific considerations, see the following resources:
