OAuth 2.0 Policies

Comply with all terms of service and policies

The use of Google API Services, which includes our implementation of OAuth 2.0, is governed by the Google APIs Terms of Service and Google API Services User Data Policy. In addition, the use of OAuth 2.0 is governed by this policy. Please read these documents carefully, as well as any other terms or policies that apply to any other Google products or services you are using. Be sure to check for updates periodically as these documents are occasionally updated.

Register an appropriate OAuth client

Every app that uses Google's OAuth 2.0 infrastructure for authentication or authorization must have at least one registered OAuth client. You must create a separate OAuth client for each platform on which your app will run, such as a web server, an Android app, an iOS app, or a limited-input device. You must choose the client type that best matches the platform. For instance, you should not use a "web" client type for your native Android or iOS app. You can register OAuth clients in the Google API Console. Please note that additional terms apply to your use of the Google Cloud Platform.

If you use Apps Script, OAuth clients are automatically created on your behalf, and you are still subject to the policies on this page. If you need to modify or manage your OAuth clients, you must switch your script project to a standard Cloud project.

Some Google development platforms, such as Firebase and Actions on Google, automatically create Google Cloud projects and OAuth clients on your behalf. If you develop on these platforms, you are still subject to the policies on this page.

Use separate projects for testing and production

For the purposes of these requirements, a "production" app meets the following criteria:

• It isn't for personal use. An app is considered to be for personal use if it's not shared with anyone else or will be used by fewer than 100 people (all of whom are known personally to you).
• It isn't used for development, testing, or staging.
• It isn't for internal use; that is, restricted to people in your Google Workspace or Cloud Identity organization.

Some policies and requirements only apply to production apps. For this reason, you must create separate projects in the Google API Console for each deployment tier, such as development, staging, and production.

Maintain a list of relevant contacts for the project

Project owners and editors must be kept up-to-date. We'll send emails to those accounts when there are notifications about your project or updates to our services. Organization administrators must ensure that a reachable contact is associated with every project in their organization. If we don't have updated contact information for your project, you might miss out on important messages that require your action. This could result in the loss of your access to the Google APIs.

Google Workspace users: Associate your project with an organization

At this time, your projects aren't required to exist within a Google Workspace or Cloud Identity Organization resource. However, you're strongly recommended to create new projects in an organization and migrate existing projects into an organization. This configuration allows your project to benefit from enterprise management including intra-domain usage. It can also prevent your project from becoming orphaned if the current project owner leaves your organization.

Handle client credentials securely

Treat your OAuth client credentials with extreme care, as they allow anyone who has them to use your app's identity to gain access to user information. Store your OAuth client information in a secure place and protect it, especially your client secret, just as you would a password. Where possible, use a secret manager, such as Google Cloud Secret Manager, to store client credentials. You must never commit client credentials into publicly available code repositories. We highly recommend that you avoid committing them to any code repository.

Handle user tokens securely

OAuth 2.0 tokens are entrusted to you by users who give you permission to act and access data on their behalf. Never transmit tokens in plaintext, and always store encrypted tokens at rest to provide an extra layer of protection in the event of a data breach. Revoke tokens when you no longer need access to a user's account or when your app no longer needs access to permissions that a user previously granted. After the tokens are revoked, delete them permanently from your application or system.

Accurately represent your identity

Provide a valid name and (optionally) a logo to show to users. This brand information must accurately represent the identity of the application. App branding information is configured when you set up OAuth 2.0 in the Google API Console Consent Screen page.

For production apps, brand information must be verified. Google can revoke or suspend access to Google API Services and other Google products and services for apps that misrepresent their identity or attempt to deceive users.

If you use Apps Script and want to verify your brand information, you must switch your script project to a standard Cloud project. If you use a Google development platform that manages OAuth clients on your behalf, such as Firebase or Actions on Google, your app settings there are used to configure your brand information. However, you must still use the Google API Console to submit your brand information for review.

Only request scopes that you need

You must only request the smallest set of scopes that are necessary for providing functionality knowingly chosen by the user. You must request scopes that require the least amount of access to user data necessary to provide that functionality. For example, an app that only uses Gmail APIs to occasionally send emails on a user's behalf shouldn't request the scope that provides full access to the user's email data. Data that you receive from Google APIs must only be used in the way that you represent to your users.

Your project configuration in the Google API Console Consent Screen page must match the list of scopes requested by your app. When a change in app functionality or in Google APIs necessitates an update to the scopes that are used, you must revoke the tokens with the previously-used scopes that are no longer in use at the earliest opportunity and update your project configuration in the Google API Console. Proper configuration is particularly important for scopes that require verification; if an app is no longer approved to use them, Google may revoke tokens that contain these scopes at any time without notice.

If you use Apps Script, the OAuth client that's automatically created for you is configured to use the scopes that Apps Script identifies from your script. If your script requires different scopes, you must specify these scopes explicitly in your script's manifest file.

Submit production apps that use sensitive or restricted scopes for verification

Certain scopes are classified as "sensitive" or "restricted," and they can't be used in production apps without review. If your production app uses sensitive or restricted scopes, you must submit your use of those scopes for verification. You can submit for verification in the Google API Console from the Consent Screen page.

If you use Apps Script and you're writing a production script that uses sensitive or restricted scopes, you must switch your script project to a standard Google Cloud Platform project before you submit your use of those scopes for verification.

Only use domains you own

Only use redirect URIs and JavaScript origins that refer to domains that you own, that you have been authorized to use (for example, as part of your employment or as a vendor or contractor of a business), or that you have been explicitly given license to use (for example, as part of a service agreement for an identity management platform).

Host a homepage for production apps

Every production app that uses OAuth 2.0 must have a publicly accessible home page. The homepage must include a description of the app's functionality, as well as links to terms of service and a privacy policy. The homepage must exist on a verified domain under your ownership.

Use secure browsers

A developer must not direct a Google OAuth 2.0 authorization request to an embedded user-agent under the developer's control. Embedded user-agents include, but are not limited to, software libraries that allow a developer to insert arbitrary scripts, alter the default routing of a request to the Google OAuth server, or access session cookies. All browsing environments must allow the user to verify the current connection to the Google OAuth server including the requested URI and connection security information.

Use secure JavaScript origins and redirect URIs

OAuth 2.0 clients for web apps must use redirect URIs and JavaScript origins that are compliant with Google’s validation rules, including using the HTTPS scheme. Google may reject OAuth requests that don't originate from or resolve to a secure context.

Handle consent for multiple scopes

When you obtain consent for multiple scopes, a user might choose to grant one or more requested scopes or deny the request. If a user doesn't grant a scope that you requested, you need to disable any related functionality in your app and not make any related API calls that will fail. If a user doesn't grant a requested scope, you may only request a new authorization after the user clearly indicates an intent to use the feature or functionality provided by the scope. Where possible, you must ask for scopes in context with incremental authorization and provide a justification to the user before you request authorization.

Handle refresh token revocation and expiration

Refresh tokens can be invalidated at any time. For example, the user could choose to revoke access to your app, a manual or automated process designed to protect users could purge the token, or the token could expire. If your app requires notification of token revocation to provide a good experience for users, you must integrate with our Cross-Account Protection service.