Tag Archives: oauth2

Improved support for service accounts in the Google Ads API

Google Ads has rolled out a new feature that allows Google Ads account administrators to grant access to a service account. Once the access has been granted, you can use the service account credentials to make API calls to that Google Ads account and other accounts in that hierarchy, if applicable. Refer to the service account guide to learn more about this option.

This new approach simplifies the Google Ads API authentication process in two important ways:

  1. If your application works entirely offline without any user interaction, then you no longer need to generate a refresh token. This means you can also avoid other steps such as configuring an OAuth consent screen and performing OAuth App verification.
  2. The new service account flow doesn’t require you to be a Google Workspace user or configure the service account for domain-wide impersonation.

We hope this simplifies your experience when working with the Google Ads API.

How to get help

If you have any questions or need help, check out the Google Ads API support page for options.

 - , Google Ads API Team

Ads API apps must complete OAuth verification

Last year, the OAuth scopes used by the following Ads APIs were classified as sensitive, requiring developers to complete the OAuth verification process for their Google Cloud projects:
  • Google Ads API & AdWords API
    • https://www.googleapis.com/auth/adwords
  • Content API for Shopping
    • https://www.googleapis.com/auth/content
  • DoubleClick Bid Manager API
    • https://www.googleapis.com/auth/doubleclickbidmanager
Any remaining OAuth clients using the above scopes that remain unverified may have their existing credentials revoked and lose access to the above APIs if they do not complete the OAuth verification process as soon as possible.

Certain apps may qualify for one of the exceptions for app verification. If your application meets any one of those exceptions, follow the steps listed for the appropriate use case. If not, you must complete OAuth verification to continue using these Ads APIs.

If you have any questions or need additional help, contact us using any of the following support options: Adam Ohren, Google Ads API Team

Google Ads and AdWords APIs upgrading authorization scope to "sensitive"

As of October 1, 2020, any Google Cloud app used to obtain credentials for the Google Ads API or AdWords API scope (https://www.googleapis.com/auth/adwords) in its projects (i.e. any new AdWords API or Google Ads API developers) will need to undergo a Google OAuth verification to avoid an unverified app screen for its users. An app, in this context, is defined as a unique OAuth 2.0 Client ID in Google Cloud. This verification is independent and in addition to any reviews conducted as part of the developer token approval process.

There is no cost for the Google verification, which typically completes in 3 to 5 business days. Information on how this process fits in the larger task of authorizing requests can be found in our guide. The verification status of a given app can be viewed at the OAuth consent screen of a Google Cloud Project.

Apps already using the Google Ads API or AdWords API scope prior to October 1, 2020 are not currently affected by this policy. However, this policy will be applied to all apps at a later date in 2021, and it is recommended that all apps undergo the Google OAuth verification process at their earliest convenience to avoid any business interruptions.

If you have any questions or need additional help, contact us via the forum or at [email protected].
- Devin Chasanoff, on behalf of the Google Ads API Team

Content API upgrading authorization scope to "sensitive"

Beginning October 1, 2020, any new Google Cloud app with a unique OAuth 2.0 Client ID used to obtain credentials for the Google Content API scope (https://www.googleapis.com/auth/content) in its projects will need to undergo a Google OAuth verification to avoid an unverified app screen for its users. Users of unverified apps that access the Content API will see warnings and the apps will have limited functionality.

There is no cost for app verification and the process typically takes 3 to 5 business days. For more information about how app verification fits into the broader process of authorizing requests, see our Using OAuth guide.

Apps already using the Content API scope prior to October 1, 2020 are not currently affected by this policy. However, this policy will be applied to all apps at a later date in 2021, and we recommend that all apps undergo the Google OAuth verification process at their earliest convenience to avoid any business interruptions.

For more information about app verification, see OAuth API verification FAQs. If you have any questions or need additional help, please reach out to us on the forum.
Benji Rothman, Content API for Shopping Team

DoubleClick Bid Manager API upgrading authorization scope to "sensitive"

On October 1, 2020, we are upgrading the classification of the authorization scope used for the DoubleClick Bid Manager API ( https://www.googleapis.com/auth/doubleclickbidmanager ) to “sensitive”. This upgrade is taking place to better secure the DBM API and the data retrieved from it.

Starting on October 1st, all unverified apps that are using the DBM API for the first time will encounter an “unverified app screen” upon attempted authentication. This screen can be removed by submitting your app to our verification process. This process usually takes about 3 to 5 business days. Information on how this process fits in the larger task of authorizing requests can be found in our guide.

Existing apps that began using the DBM API scope before October 1st will not see the “unverified app screen” and will not immediately need to go through the verification process. However, all apps accessing sensitive scopes will require explicit verification before the end of 2021. In anticipation of this requirement, it is recommended that existing apps complete the verification process at their earliest convenience.

If you run into issues or need help with this process, please contact us using our support contact form.
- Trevor Mulchay, Display & Video 360 API Team

Google Cloud for Student Developers: Accessing G Suite REST APIs

Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

Recently, we introduced the "Google Cloud for Student Developers" video series to encourage students majoring in STEM fields to gain development experience using industry APIs (application programming interfaces) for career readiness. That first episode provided an overview of the G Suite developer landscape while this episode dives deeper, introducing G Suite's HTTP-based RESTful APIs, starting with Google Drive.

The first code sample has a corresponding codelab (a self-paced, hands-on tutorial) where you can build a simple Python script that displays the first 100 files or folders in your Google Drive. The codelab helps student (and professional) developers...

  1. Realize it is something that they can accomplish
  2. Learn how to create this solution without many lines of code
  3. See what’s possible with Google Cloud APIs

While everyone is familiar with using Google Drive and its web interface, many more doors are opened when you can code Google Drive. Check this blog post and video for a more comprehensive code walkthrough as well as access the code at its open source repository. What may surprise readers is that the entire app can be boiled down to just these 3-4 lines of code (everything else is either boilerplate or security): 

    DRIVE = discovery.build('drive', 'v3', http=creds.authorize(Http()))
    files = DRIVE.files().list().execute().get('files', [])
    for f in files:
        print(f['name'], f['mimeType'])

Once an "API service endpoint" to Google Drive is successfully created, calling the list() method in Drive's files() collection is all that's needed. By default, files().list() returns the first 100 files/folders—you can set the pageSize parameter for a different amount returned.

The video provides additional ideas of what else is possible by showing you examples of using the Google Docs, Sheets, and Slides APIs, and those APIs will be accessed in a way similar to what you saw for Drive earlier. You'll also hear about what resources are available for each API, such as documentation, code samples, and links to support pages.

If you wish to further explore coding with G Suite REST APIs, check out some additional videos for the Drive, Sheets, Gmail, Calendar, and Slides APIs. Stay tuned for the next episode which highlights the higher-level Google Apps Script developer platform.

We look forward to seeing what you build with Google Cloud!

Announcing Google Ads API Doctor

We have heard from users that correctly configuring a client library and provisioning OAuth2 credentials can be challenging, so today we are introducing Google Ads API Doctor, a new tool that will analyze your client library environment. The program will:
  • Verify that your OAuith2 credentials are correctly configured and ready to make API calls.
  • Guide you through fixing any OAuth2 problems it detects and verify the corrected configuration.
The initial version of this tool will help you analyze and fix issues related to OAuth2 configuration, including the following common issues:
  • Invalid refresh token: The program will identify this and guide you through the process to obtain a valid token, back up your configuration file, and write the new value to your active configuration file.
  • Permission denied: There are several OAuth errors that sound similar, such as user permission denied and permission denied. The program identifies that in the first case it is caused by an invalid refresh token and in the second it’s because the Google Ads API is disabled in the Google API Console.
If you want to send the output to support, you can run your scenario with the PII flag to hide your Personally Identifiable Information (PII) and copy the screen output. To gather even more information, you can use the verbose flag to see the low-level JSON that is returned.

We are releasing this project as open source per Google’s open source initiative, and we encourage contributions. See contributing to Google open source to learn more about how to contribute to this project. As always, share your feedback on the Google Ads API forum.

Bob Hancock and Poki Chui, Google Ads API Team

Multi-factor authentication policy for Google Ads accounts

Today, we are rolling out a feature that allows the administrative users of Google Ads accounts to set a required multi-factor authentication policy, including 2-Step Verification. When this new authentication policy is enabled on a particular Google Ads account, all users who want to access that account must have their Google accounts enrolled in 2-Step Verification.

Note: The Google account users can alternately fulfill this requirement by enrolling their accounts in Advanced Protection.

What will happen to your API access?
If 2-Step Verification is required for a particular Google Ads account, then 2-Step Verification also needs to be set up for the Google account used to generate the OAuth2 refresh token accessing the Google Ads account. Follow this link to opt in to 2-Step Verification. Failing to do so will result in the AuthorizationError.TWO_STEP_VERIFICATION_NOT_ENROLLED error when you try to access the Google Ads account.

Access to the Google Ads account will be restored once you opt in to the 2-Step Verification. The multi-factor authentication policy does not affect the way you access the AdWords API or the Google Ads API Beta in any other aspects--you can still use an OAuth2 refresh token and a developer token to access the AdWords API and the Google Ads API Beta as usual.

2-Step Verification ensures only strongly verified users have access to your Google accounts. Opt in now to avoid hitting the AuthorizationError.TWO_STEP_VERIFICATION_NOT_ENROLLED error in advance.

As always, if you have any questions or concerns, please post on our forum.
 - , AdWords API Team

Updating developer identity guidelines and registration processes to protect users

Posted by Naveen Agarwal, Identity Team

Last week, we took immediate action to protect users from a phishing attack that attempted to abuse the OAuth authorization infrastructure.

Today, we’re supplementing those efforts to help prevent these types of issues in the future. These changes may add some friction and require more time before you are able to publish your web application, so we recommend that you plan your work accordingly.

Updating app identity guidelines

As our Google API user data policy states, apps must not mislead users. For example, app names should be unique to your application and should not copy others'.

To further enforce this policy, we are updating our app publishing process, our risk assessment systems, and our user-facing consent page in order to better detect spoofed or misleading application identities. You may see an error message as you’re registering new applications or modifying existing application attributes in the Google API Console, Firebase Console, or Apps Script editor as a result of this change.

New review processes and restrictions on web apps requesting user data

We have also enhanced our risk assessment for new web applications that request user data.

Based on this risk assessment, some web applications will require a manual review. Until the review is complete, users will not be able to approve the data permissions, and we will display an error message instead of the permissions consent page. You can request a review during the testing phase in order to open the app to the public. We will try to process those reviews in 3-7 business days. In the future, we will enable review requests during the registration phase as well.

You can continue to use your app for testing purposes before it is approved by logging in with an account registered as an owner/editor of that project in the Google API Console. This will enable you to add additional testers, as well as initiate the review process.

We also recommend developers review our earlier post outlining their responsibilities when requesting access to user data from their applications. Our teams will continue our constant efforts to support a powerful, useful developer ecosystem that keeps users and their data safe.