Tag Archives: oauth

How to integrate your web app with Google Ads

TL;DR: You can now have a web application integrated with Google Ads in just a few minutes!

Google Ads
Google Ads is an online advertising platform where advertisers can create and manage their Google marketing campaigns. The Google Ads API is the modern programmatic interface to Google Ads and the next generation of the AdWords API. It enables developers to interact directly with the Google Ads platform, vastly increasing the efficiency of managing large or complex Google Ads accounts and campaigns.

A typical use case is when a company wants to offer Google ads natively on their platform to their users. For example, customers who have an online store with Shopify can promote their business using Google ads, with just a few clicks and without needing to go to the Google Ads platform. They’re able to do it directly on Shopify’s platform—the Google Ads API makes this possible.

Demo App
Francisco Blasco, Strategic Technical Solutions Manager at Google, designed and built an open source web application that is integrated with Google Ads and Business Profile (aka Google My Business).

Anyone can use the app, called Fran Ads, to save significant time on product development. Just follow the simple installation steps in the README files (frontend README file and backend README file) on the GitHub repo! The app uses React for the frontend, and Django for the backend; two of the most popular web frameworks.

App's Logo


Check out a product demo here! You can have this app running in your local machine in a few minutes. To learn how, check out the video tutorial.

Blasco acts as an external Product Manager for Google’s strategic partners, driving the entire product development lifecycle. He created this project to help Google’s partners and businesses seeking to offer Google Ads to their users.

The goal is to accelerate the Google Ads integration process and decrease associated development costs. Some companies are using Fran Ads to see what an integration looks like, while others are using the technical guide to learn how to start using the Google Ads API.

In general, companies can use Fran Ads as an SDK to begin working with elements within the Google Ads API, and serve as a guidance system for integrating with Google. This project will minimize the number of times the wheel needs to be reinvented, accelerating innovation and facilitating adoption. Developers can clone the code repositories, follow the steps, and have a web app integrated with Google Ads in just a few minutes. They can adapt and build on top of this project, or they can just use the functions they need for the features they want to develop



App Architecture

Furthermore, you will learn how to create credentials to consume Google APIs; specifically, the README files show how to create a project on Google Cloud Platform (GCP), and how to set it up correctly so a web app can consume Google Ads API and Business Profile APIs.

Also, you will learn how refresh tokens work for Google APIs, and how to manage them for your web application.

Francisco wrote a detailed technical guide explaining how to build every feature of the app. Some of the most important features are:
        1. Create a new Google Ads account
        2. Link an existing Google Ads account
        3. OAuth authentication & authorization
        4. Refresh token management
        5. List of Google Ads accounts associated with Google account
        6. Reporting on performance for all campaign types
        7. Create Smart Campaign (automated ads on Google and across the web)
        8. Edit Smart Campaign settings

As you can see from the list above, the app will create Smart Campaigns — a simplified, automated campaign designed for new advertisers and SMBs

Google made public the suggestion services through the Google Ads API. Fran Ads uses those services to recommend keyword themes, headlines & descriptions for the ad, and budget. These recommendations are specific for each advertiser, depending on several factors such as type of business, location, and keyword themes.



An example of three Google recommendations for an advertiser.


The image above shows the final step of creating a Smart Campaign on Fran Ads. In this step, users have to set a daily budget for the campaign. Not only will you receive recommendations for the budget, but an estimate of how many ad clicks you will get per month. This is a great feature for users who are new to digital marketing and aren’t aware of their spending needs.

You can also see an alert message that the budget can be changed anytime, so users can pause spending on the campaign. This is important because many new users, especially SMBs, have doubts about spending on something new. Therefore, it is important to communicate to them that the decision they are making at that moment is not set in stone.

When you start using Fran Ads, you will see there is guidance so users complete the tasks they want.


Guidance on how to complete tasks based on Google’s best practices.


Furthermore, the app is designed based on Google’s best practices. For example, when users are creating a Smart Campaign, in step three (see the above image) they need to select keyword themes (group of keywords). If you choose “bakery” as the keyword theme, your ad is eligible to show when people search for “bakery near me”, “local bakery”, and “cake shop”.

Google’s best practices suggest that advertisers use between seven and ten keyword themes per campaign. Therefore, Fran Ads is designed for users to select up to seven keyword themes. Refer to the image of step three when creating a Smart Campaign on Fran Ads. However, you can set it to ten if you like.

The technical guide also provides:

        1. Production-ready code for both the frontend and backend
        2. Engineering flow diagrams
        3. Best practices
        4. High-fidelity mockups
        5. App architecture and structure diagrams
        6. Workarounds to current bugs on Google Ads API v9
        7. Important information on how to handle important tasks necessary for integrating your platform with Google Ads
        8. Help with the design strategy for the UX and design elements of the UI.

Important resources

See below the list summarizing the important resources that will help you integrate with Google Ads easier, faster, and better.
        1. Frontend repo: all the code for the frontend of Fran Ads.
        2. Backend repo: all the code for the backend of Fran Ads.
        3. Technical guide: 3 sections: ‘Before Starting’, ‘Configurations & Installation’, and ‘Build web              app’. In section 3, you have explanations on how to build all the features of the app.
        4. Product demo: 15-minute demo of Fran Ads showing many core features.
        5. Video tutorial: 17-minute tutorial on how to set up and run Fran Ads.


By Francisco Blasco – Launch, Channel Partners

Making Google OAuth interactions safer by using more secure OAuth flows

Posted by Vikrant Rana, Product Manager and Badi Azad, Group Product Manager, Google

At Google, we constantly strive to provide safer ways for users to sign-in and share their Google account data with third-party applications. In the spirit of that work, we will be rolling out a set of protections against phishing and app impersonation attacks during the OAuth interactions.

The Google sign-in and authorization flows are powered by the Google OAuth platform and over the years we have developed and supported a number of ways for app developers to integrate with supported OAuth flows. With the goal of keeping users safer online, we will end support for two legacy flows and will require developers to migrate to alternative implementation methods that offer greater protections.

To ensure a smooth transition and avoid any service interruption we will give ample time to implement and meet the compliance dates which are specified below. We will share further updates on this rollout via email so please make sure your support email address is up to date in project settings on the Google API console.

Loopback IP address flow will be disallowed for native iOS, Android and Chrome OAuth client types

The Loopback IP address flow is vulnerable to man in the middle attack where a malicious app, accessing the same loopback interface on some operating systems, may intercept the OAuth response and gain access to the authorization code. We intend to remove this threat vector by disallowing this flow for iOS, Android and Chrome app OAuth client types. The existing clients will be able to migrate to more secure implementation methods. New clients will be unable to use this flow starting on March 14, 2022.

What do I need to do

Determine if your app is using the Loopback IP address flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=http://127.0.0.1:port or http://[::1]:port">http://[::1]:port or

http://localhost:port

Migrate to an alternative flow

If your app is using the Loopback IP address method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Mar 14, 2022 - new OAuth usage will be blocked for the Loopback IP address flow
  • Aug 1, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests one month before the compliance date
  • Aug 31, 2022 - the Loopback IP address flow is blocked for existing clients

OAuth out-of-band (oob) flow will be deprecated

OAuth out-of-band (OOB) is a legacy flow developed to support native clients which do not have a redirect URI like web apps to accept the credentials after a user approves an OAuth consent request. The OOB flow poses a remote phishing risk and clients must migrate to an alternative method to protect against this vulnerability. New clients will be unable to use this flow starting on Feb 28, 2022.

What do I need to do

Determine if your app is using the OOB flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=urn:ietf:wg:oauth:2.0:oob or urn:ietf:wg:oauth:2.0:oob:auto or oob

Migrate to an alternative flow

If your app is using the OOB method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Feb 28, 2022 - new OAuth usage will be blocked for the OOB flow
  • Sep 5, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests
  • Oct 3, 2022 - the OOB flow is deprecated for existing clients

User-facing warning message

A user-facing warning message may be displayed for non-compliant requests one month before the aforementioned OAuth methods are due to be blocked. The message will convey to the users that the app may be blocked soon while displaying the support email that you have registered in the OAuth consent screen in Google API Console.

[Sample user-facing warning]

The developers can acknowledge the user-facing warning message and suppress it by passing a query parameter in the authorization call as shown below.

  • Go to the code in your app where you send requests to Google's OAuth 2.0 Authorization Endpoint.
  • Add a parameter with a value of the enforcement date
    • For OOB: Add an ack_oob_shutdown parameter with a value of the enforcement date: 2022-10-03. Example: ack_oob_shutdown=2022-10-03
    • For Loopback IP address: Add an ack_loopback_shutdown parameter with a value of the enforcement date: 2022-08-31. Example: ack_loopback_shutdown=2022-08-31

User-facing error message

If an app is not updated to meet compliance by the required date the authorization requests will be blocked and users may encounter an invalid request error screen (sample shown below).

[Sample user-facing error]

Making Google OAuth interactions safer by using more secure OAuth flows

Posted by Vikrant Rana, Product Manager and Badi Azad, Group Product Manager, Google

At Google, we constantly strive to provide safer ways for users to sign-in and share their Google account data with third-party applications. In the spirit of that work, we will be rolling out a set of protections against phishing and app impersonation attacks during the OAuth interactions.

The Google sign-in and authorization flows are powered by the Google OAuth platform and over the years we have developed and supported a number of ways for app developers to integrate with supported OAuth flows. With the goal of keeping users safer online, we will end support for two legacy flows and will require developers to migrate to alternative implementation methods that offer greater protections.

To ensure a smooth transition and avoid any service interruption we will give ample time to implement and meet the compliance dates which are specified below. We will share further updates on this rollout via email so please make sure your support email address is up to date in project settings on the Google API console.

Loopback IP address flow will be disallowed for native iOS, Android and Chrome OAuth client types

The Loopback IP address flow is vulnerable to man in the middle attack where a malicious app, accessing the same loopback interface on some operating systems, may intercept the OAuth response and gain access to the authorization code. We intend to remove this threat vector by disallowing this flow for iOS, Android and Chrome app OAuth client types. The existing clients will be able to migrate to more secure implementation methods. New clients will be unable to use this flow starting on March 14, 2022.

What do I need to do

Determine if your app is using the Loopback IP address flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=http://127.0.0.1:port or http://[::1]:port">http://[::1]:port or

http://localhost:port

Migrate to an alternative flow

If your app is using the Loopback IP address method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Mar 14, 2022 - new OAuth usage will be blocked for the Loopback IP address flow
  • Aug 1, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests one month before the compliance date
  • Aug 31, 2022 - the Loopback IP address flow is blocked for existing clients

OAuth out-of-band (oob) flow will be deprecated

OAuth out-of-band (OOB) is a legacy flow developed to support native clients which do not have a redirect URI like web apps to accept the credentials after a user approves an OAuth consent request. The OOB flow poses a remote phishing risk and clients must migrate to an alternative method to protect against this vulnerability. New clients will be unable to use this flow starting on Feb 28, 2022.

What do I need to do

Determine if your app is using the OOB flow

You can inspect your app code or the outgoing network call (in case your app is using an OAuth library) to determine if the Google OAuth authorization request your app is making has the following values for “redirect_uri” parameter.

redirect_uri=urn:ietf:wg:oauth:2.0:oob or urn:ietf:wg:oauth:2.0:oob:auto or oob

Migrate to an alternative flow

If your app is using the OOB method you need to migrate to another method which is more secure by default. Please consider the following alternative methods for migration.

Key dates for compliance

  • Feb 28, 2022 - new OAuth usage will be blocked for the OOB flow
  • Sep 5, 2022 - a user-facing warning message may be displayed to non-compliant OAuth requests
  • Oct 3, 2022 - the OOB flow is deprecated for existing clients

User-facing warning message

A user-facing warning message may be displayed for non-compliant requests one month before the aforementioned OAuth methods are due to be blocked. The message will convey to the users that the app may be blocked soon while displaying the support email that you have registered in the OAuth consent screen in Google API Console.

[Sample user-facing warning]

The developers can acknowledge the user-facing warning message and suppress it by passing a query parameter in the authorization call as shown below.

  • Go to the code in your app where you send requests to Google's OAuth 2.0 Authorization Endpoint.
  • Add a parameter with a value of the enforcement date
    • For OOB: Add an ack_oob_shutdown parameter with a value of the enforcement date: 2022-10-03. Example: ack_oob_shutdown=2022-10-03
    • For Loopback IP address: Add an ack_loopback_shutdown parameter with a value of the enforcement date: 2022-08-31. Example: ack_loopback_shutdown=2022-08-31

User-facing error message

If an app is not updated to meet compliance by the required date the authorization requests will be blocked and users may encounter an invalid request error screen (sample shown below).

[Sample user-facing error]

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:

Google OAuth incremental authorization improvement

Posted by Vikrant Rana, Product Manager, and Badi Azad, Group Product Manager

Summary

Google Identity strives to be the best stewards for Google Account users who entrust us to protect their data. At the same time, we want to help our developer community build apps that give users amazing experiences. Together, Google and developers can provide users three important ways to manage sharing their data:

  1. Give users control in deciding who has access to their account data
  2. Make it easier and safer for users to share their Google Account data with your app when they choose to do so
  3. Make it clear to users the specific data they are sharing with apps

What we are doing today

In service of that stewardship, today we are announcing an OAuth consent experience that simplifies how users can share data with apps. This experience also improves the consent conversion for apps that use incremental authorization, which requests only one scope. Users can now easily share this kind of request with a single tap.

Screenshot compares the previous screen and the new screen you see when Example app wants to access your account

Previous Screen                                               New Screen

A quick recap

Let’s summarize a few past improvements so you have a full picture of the work we have been doing on the OAuth consent flow.

In mid-2019, we significantly overhauled the consent screen to give users fine-grained control over the account data they chose to share with a given app. In that flow, when an app requested access to multiple Google resources, the user would see one screen for each scope.

In July 2021, we consolidated these multiple-permission requests into a single screen, while still allowing granular data sharing control for users. Our change today represents a continuation of improvements on that experience.

Screenshot that shows the option to select what Example app can access

The Identity team will continue to gather feedback and further enhance the overall user experience around Google Identity Services and sharing account data.

What do developers need to do?

There is no change you need to make to your app. However, we recommend using incremental authorization and requesting only one resource at the time your app needs it. We believe that doing this will make your account data request more relevant to the user and therefore improve the consent conversion. Read more about incremental authorization in our developer guides.

If your app requires multiple resources at once, make sure it can handle partial consent gracefully and reduce its functionality appropriately as per the OAuth 2.0 policy.

Related content