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 **External** user types in the Google Cloud Console. For more details, see [User type: External](https://support.google.com/cloud/answer/15549945#zippy=%2Cexternal).
- **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 **Internal** user 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](https://support.google.com/cloud/answer/15549945#zippy=%2Cinternal).

## 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](https://support.google.com/cloud/answer/9110914) and
[token expiration rules](https://developers.google.com/identity/protocols/oauth2#expiration).

| 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

> [!NOTE]
> **Note:** The following controls and behaviors apply only if your application is accessed by Google Workspace users or if your project is associated with a Google Workspace organization.

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 **Block** any 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)](https://support.google.com/a/answer/162106) 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 **not** override 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
**Testing** status.

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:

- [Comply with
  OAuth 2.0 policies](https://developers.google.com/identity/protocols/oauth2/production-readiness/policy-compliance)
- [Additional
  considerations for Google Workspace](https://developers.google.com/identity/protocols/oauth2/production-readiness/google-workspace)
- [Control which apps access Google
  Workspace data](https://support.google.com/a/answer/7281227)