As part of improving security for Google Ads accounts, the Google Ads API will start requiring Multi-factor authentication (MFA) for Google Ads API users. These important security updates will start rolling out from April 21, 2026, and will be enabled for all users over the next few weeks.

What is MFA?

MFA, also known as 2-step verification or 2SV, is an important security measure. In addition to your password, MFA requires another proof of identity, known as an authentication factor, to successfully sign in to an account. By requiring the second factor, you’re making it significantly harder for unauthorized users to breach your account, and a compromised password alone is not enough to gain access.

What is changing?

Once this change goes live, users following the user authentication workflow to generate new OAuth 2.0 refresh tokens for Google Ads API will always be challenged with a second factor for authentication in addition to a username and password.

If you don’t have 2-step verification enabled, you will be prompted to add a 2-step verification method.

What action do I need to take?

You may be affected by this change, depending on the authentication workflow that your application uses.

  • Service account workflow: Service account workflows are not affected by this change, so no action is required. We strongly recommend using service account workflow for applications that require automated or offline workflows.
  • User authentication workflow: If your app generates OAuth 2.0 refresh tokens for users, you will be affected as follows:
    • Existing OAuth refresh tokens are not affected by this change. They will continue to work as usual, and you won’t be prompted for reauthorization when obtaining OAuth access tokens.
    • New users will be challenged with a second factor for authentication in addition to a username and password.

What other platforms are affected by this change?

If you use Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service or Data Studio to manage Google Ads, you will start getting challenged with a second factor for authentication in addition to a username and password. If you don’t have 2-step verification enabled, you will be prompted to add a 2-step verification method.

How can users check and enable MFA?

Users can check whether MFA is enabled for their account by opening the Security tab of their Google Account settings page. The 2-Step Verification setting is displayed in the How you sign in to Google section. If MFA isn’t enabled, follow the on-screen steps displayed in this section.

If you don't see the 2-Step Verification option for your account, your administrator might have disabled it. Contact your administrator for assistance.

Troubleshooting

Q: When I navigate to the Google Account settings page, I don’t see the 2-Step Verification option for my account.

A: If you don't see the 2-Step Verification option for your account, your administrator might have disabled it. Contact your administrator for assistance.

Q: I don’t have a 2-step verification option enabled for my account. When I attempt to sign in, I get an error that "Google couldn’t verify this account belongs to you." and I am prompted to Recover account instead of prompting me to add a 2-step verification.

A: In certain situations, Google needs additional verification before letting you add a second factor to your account. To fix the issue, navigate to the Security tab of your Google Account settings page. The 2-Step Verification setting is displayed in the How you sign in to Google section. If 2-Step Verification isn’t enabled, follow the on-screen steps displayed in this section. Wait for a few minutes and attempt signing into the Google Ads API application again.

For any questions or further discussion regarding this update, please connect with us on the "Google Advertising and Measurement Community" Discord server.

 - , Google Ads API Team

Labels: ,

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
Labels: , , , , , , ,

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 googleadsapi-support@google.com.
- Devin Chasanoff, on behalf of the Google Ads API Team
Labels: , , ,

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
Labels: , , ,

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
Labels: , , ,

We are making the following changes to AdWords OAuth Scopes during the week of January 8, 2018.

Invalid OAuth scopes will no longer be supported
One mistake that developers make when obtaining an OAuth2 access or refresh token for AdWords API is to use the service URL prefix (e.g. https://adwords.google.com/api/adwords/cm/v201708, https://adwords.google.com/api/adwords/reportdownload/v201708) as OAuth2 scope. When we switched to OAuth2, this was a common source of confusion for AdWords API users, so we allowed developers to use these scopes. Since most users are now using the new scope, we are sunsetting these old scopes. Any refresh tokens authorized with the old scopes will stop working with an invalid_scope error. If this error occurs, you will have to re-authorize your users with the proper AdWords scope (https://www.googleapis.com/auth/adwords) to continue making API calls.

Change to permitted OAuth 2.0 scopes when creating Location Extension feeds
When creating a Feed for Location Extensions, make sure you set the OAuthInfo object’s httpRequestUrl field to the AdWords API scope (https://www.googleapis.com/auth/adwords). In the past, we also supported using the Google My Business scope (https://www.googleapis.com/auth/plus.business.manage) for this field; we are sunsetting support for this scope. Similarly, the httpAuthorizationHeader field must have an access token that is authorized for the AdWords API scope.

While we don’t expect most users to be affected by these changes, make sure you review your code and make necessary changes if needed. As always, if you have any questions, let us know on the AdWords API forum.
Anash P. Oommen, AdWords API Team
Labels: , ,

For those of you who’d prefer to generate an OAuth refresh token using only a browser, there's a new guide on how to use the OAuth 2.0 Playground:

https://developers.google.com/adwords/api/docs/guides/oauth_playground

The guide walks you through the authorization setup required by the AdWords API for a Web application--via a browser session--without the need to execute any command-line scripts.

More OAuth resources
Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.

- Josh Radcliff, AdWords API Team
Labels: ,

ClientLogin authentication support for the AdWords API and the DoubleClick Ad Exchange API will sunset along with v201309 on July 21st, 2014. You only have 3 weeks left to migrate!

We have plenty of resources to help you migrate. It might take longer than you expect to migrate to OAuth 2.0, especially if you don't already use a single top-level MCC to manage your AdWords accounts or if you are a DoubleClick Ad Exchange customer.

Start your migration as soon as possible and reach out to us early on the AdWords API Forum or the DoubleClick Ad Exchange API Forum with any questions.

- Ray Tsang, AdWords API Team
Labels: , , ,

ClientLogin authentication support for the AdWords API and the DoubleClick Ad Exchange SOAP API will sunset along with v201309 on July 21st, 2014. You only have two months left to migrate - don’t wait until the last minute!

We have plenty of resources to help you migrate. It might take longer than expected to migrate to OAuth2, especially if you don't already use a single top-level MCC to manage your AdWords accounts or if you are a DoubleClick Ad Exchange customer.

Start your migration as soon as possible and reach out to us early on the AdWords API Forum or the DoubleClick Ad Exchange API Forum with any questions.

- Ray Tsang, AdWords API Team
Labels: , , , ,

ClientLogin authentication support for the AdWords API will sunset along with v201309 on July 21st, 2014. But it doesn’t mean you should wait till the last minute to migrate!

We have plenty of resources to help you migrate. It might take longer than expected to migrate to OAuth2, especially if you don't already use a single top-level MCC to manage your AdWords accounts.

Start your migration as soon as possible and reach out to us early on the AdWords API Forum with any questions.

- Ray Tsang, AdWords API Team
Labels: , , ,

Is your AdWords API client application still using ClientLogin? If so, you should start your migration from ClientLogin to OAuth 2.0 as soon as possible.

Your AdWords API client applications must be fully migrated to OAuth 2.0 before ClientLogin is sunset in June 2014, as previously announced. If you don't migrate by then, your client applications will fail -- they won't be able to access your MCC account or any AdWords account via the API.

How do I get started?

We have prepared a ClientLogin to OAuth 2.0 migration guide which includes:

  • Detailed migration strategies based on use cases
  • Code samples to automate parts of the migration
  • Client library-specific migration videos, code, and pertinent OAuth 2.0 documentation

You don't want to worry about your applications failing, so get started now. For most developers with a single top level MCC, this migration will involve only a few configuration and code changes. But if you run into any issues with your particular application or AdWords accounts, you'll be glad you left plenty of time before the sunset to work things out.

We are here to help

If you run into any issues, or if you have any questions, please reach out to us on the AdWords API Forum.

- Ray Tsang, AdWords API Team

Labels: , ,

Authorization is an important concern when writing software that interacts with Google’s Ads APIs. We’ve recently improved our documentation and published resources documenting how to use OAuth2 with many of our Ads APIs.

OAuth2 is an authorization flow that allows you to direct a user to a specially crafted Google URL where they grant permissions to your software to make changes to their account. With an authorized access token, you can make requests to Ads APIs on the user’s behalf. Benefits include:
  • Users don’t need to provide a username and password - they just log into Google.
  • No CAPTCHA challenges.
  • Limited scope - the user will only be prompted to grant access to a specific part of their account. For example, they could grant access to AdWords without the application being able to see their email or calendar.
OAuth2 is supported by:
The Ads API client libraries supported by Google have built-in support for OAuth2. We’ve included examples demonstrating how to use this feature in all client libraries. See your respective product and language product sites for more information on OAuth2.

We’re also hosting a Google Developers Live event covering how to use OAuth2 on August 23rd. This will be recorded if you can’t make it. If you have any questions about OAuth2, please post on the respective product API forums.

 - , AdWords API Team
Labels: , , , , , ,

Today we’ve released the newest version of the DFP API, v201206, which adds a significant number of reporting improvements. The new release also fully supports OAuth 2.0 as the authentication mechanism of choice and we encourage you to switch to OAuth 2.0 from ClientLogin or OAuth 1.0a. A full list of improvements from today’s release can be found on our release notes page.

Reporting improvements

In a few of our recent hangouts, we received the feedback that while our reports were great for generating important performance metrics, the CSV files that you downloaded were not always easily machine readable. To make it easier for you to consume reports, we’ve created a new ExportFormat - CSV_DUMP. Below is a list of the features of this new format:

  • Columns are now shown as Dimension.ENUM_VALUE or Column.ENUM_VALUE
  • All money values are now displayed in micro format in the currency of the network
  • All dates are now displayed as YYYY-MM-DD
  • All date-times are now displayed as YYYY-MM-DDThh:mm:ss±hh:mm
  • There is no "pretty printing" of values (i.e. commas) and there is no total row
You may also notice that the v201204 CSV export format has been replaced by CSV_EXCEL, which can be imported into Excel-like products.

As an important note to some of our developers, after upgrading to v201206, you will most likely need to update your code; many column names have changed to reflect a more accurate description of what metrics they are indeed pulling. For example, the column TOTAL_IMPRESSIONS has been changed to TOTAL_INVENTORY_LEVEL_IMPRESSIONS because the v201204 column could only be used with dimensions like AD_UNIT_NAME on the inventory level, i.e. it could not be used with line items, orders, companies or creatives. Alternatively, TOTAL_LINE_ITEM_LEVEL_IMPRESSIONS in v201206 should now be used with dimensions like LINE_ITEM_NAME and ORDER_NAME for instances where you need to include dynamic allocation impressions from AdSense or Ad Exchange line items. To determine how each column should be updated, visit the old column’s reference page and look for the phrase that begins with “Replaced with …”, e.g.

    Replaced with TOTAL_INVENTORY_LEVEL_IMPRESSIONS beginning in v201206.

Lastly, we’ve improved formatting for inventory reports that don’t use top level ad unit views. Most importantly, the duplicate columns clicks and impressions issue for hierarchical views has been fixed and the flat view report will now match how the report is downloaded from the UI.

OAuth 2.0

If you are an eagle-eyed developer, you may have noticed that we recently added OAuth 2.0 information to our authentication page. OAuth 2.0 is now fully supported in the DFP API and we are progressively adding support in our client libraries; Java, Python, .Net , and Ruby currently have full support, while PHP will very soon. In fact, our DFP test playground already uses OAuth 2.0 with the Java library. Please stay tuned to the project sites or the forum for announcements regarding future support.

Our next hangout is July 18th and we’ll be taking your report questions or anything else you might have on your mind. As always, let us know if you have any questions on our forum.

 - , DFP API Team
Labels: , , ,


The AdWords API Python Google App Engine demo has been updated to use v201109 (and clientCustomerId) and now has its source control hosted at the new project site.

In addition, we are happy to announce the release of a new Python Google App Engine demo - this one demonstrating AdHoc reports running on Google App Engine using OAuth 1.0a for the authentication. This demo allows you to select as many or as few child accounts as you wish to run a report against and will download the reports asynchronously using a Task Queue one by one. Reports are stored in the Google App Engine Blobstore and can be downloaded by the user once they have been processed.

The new demo also shows how to perform the OAuth flow in a web application context and how to store the oauth_token and oauth_token_secret in the Google App Engine datastore. OAuth is used both to query the API for a list of accounts as well as to download the reports.

You can download the Google App Engine demo and use the Python Development Google App Engine Server to play around with the code without the need for an existing Google App Engine account. If you have any questions or would like to discuss this new demo, please post on the forum.

 - , AdWords API Team
Labels: , , ,