If your app targets an [external user type](https://support.google.com/cloud/answer/10311615#user-type-external), you might want to address the widest possible audience of Google Accounts, which includes Google Accounts administered by a Google Workspace organization. Google Workspace administrators can use [API access controls](https://support.google.com/a/answer/7281227) to enable or restrict access to Google Workspace APIs for customer-owned and third-party applications and service accounts. This feature lets Google Workspace administrators restrict access to only OAuth client IDs that are trusted by the organization, which reduces the risk associated with third-party access to Google Services. To reach the widest possible audience of Google Accounts and to foster trust, we recommend the following: - Submit your app for verification by Google. If applicable, you must submit your app for [brand verification](https://developers.google.com/identity/protocols/oauth2/production-readiness/brand-verification), as well as [sensitive](https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification) and [restricted](https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification) scopes verification. Google Workspace admins can view your app's verified status, and they might trust apps that Google verifies more than apps with an [unverified](https://support.google.com/a/answer/9352843) or unknown status. - Google Workspace admins can give your app's OAuth client IDs access to restricted services and the high-risk scopes within. If you include your app's OAuth client ID in your help documents, you can provide Google Workspace admins, and advocates for your app within their organizations, the information needed to give access to your app. It can also help them understand what configuration changes might be needed before your app can access an organization's data. - Routinely monitor your user support email address that you provide when you configure your OAuth [Consent Screen page](https://console.developers.google.com/apis/credentials/consent). Google Workspace admins can view this email address when they review your app's access, and they might reach out to you with possible questions and concerns. ## The impact of Google Workspace administrator controls on token validity Google Workspace administrators can implement several controls that indirectly affect the validity and lifetime of OAuth tokens. - **Google Cloud Session Control:** Google Workspace administrators can set session lengths for Google Cloud services (e.g., Google Cloud Console, gcloud CLI). This setting applies to any application, including third-party apps, that requires user authorization for Google Cloud scopes. Exceeding this session length can invalidate refresh tokens associated with those Google Cloud scopes. For more details, see [Set session length for Google Cloud services](https://support.google.com/a/answer/9368756). - **General Google Services Session Control:** Administrators can also control web session duration for services like Gmail on the web. This forces users to sign in again to the Google web interface after the session expires. However, this control typically does **not** invalidate OAuth refresh tokens granted to third-party applications for accessing API data (such as Gmail, Drive, or Calendar APIs), unless the scopes are specifically Google Cloud related. For more information, see [Set session length for Google services](https://support.google.com/a/answer/7576830). - **App Access Control:** Administrators can block apps, limit their access to certain services, or revoke access entirely, which renders associated refresh tokens invalid. - **Domain-wide Delegation (DWD):** While DWD does not change token lifetimes, it allows administrators to pre-authorize apps, bypassing user consent and directly managing the app's access to organization data. ## Associate your project with an organization If you are a Google Workspace user, it is strongly recommended that your developer project is created inside a [organization resource](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy#organizations) within your [Google Workspace](https://gsuite.google.com/) or [Cloud Identity](https://cloud.google.com/identity) account. This lets you use [enterprise management features](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy#benefits_of_the_organization_resource), such as [important notifications](https://cloud.google.com/resource-manager/docs/managing-notification-contacts), access control and project lifecycle management, without tying it to an individual developer account. Otherwise, it might be difficult (or impossible) to transfer to a new owner in the future. When setting up your developer project, [create it in an organization](https://cloud.google.com/resource-manager/docs/creating-managing-projects) or [migrate your existing projects into an organization](https://cloud.google.com/resource-manager/docs/migrating-projects-billing).