Introduction

All Ads APIs use OAuth2 as their authentication mechanism. To make calls to these APIs, you need to create an OAuth2 client ID and secret from Google Developers Console. This wiki article walks you through the process of creating one.

Accessing the Google Developers Console

The Google Developers Console is available from https://console.developers.google.com. All the projects you have under the console can be viewed on this page by default.

Creating a new project

You can create a new project by clicking the Create Project button. This brings up the following screen.

You can provide a friendly name on the Project name field, and a unique string in the Project ID field; click the Create button to create the project. This will create the project and list it on your home page. You can navigate within the project by clicking the corresponding link on the Projects list.

#Setting up a project

Once you create the project, you need to configure it by editing the Consent screen, and creating one or more OAuth2 client IDs.

Setting up the consent screen

The consent screen is shown to the users whenever your application requests access to their data. You can access it from APIs & auth => Consent screen from the left hand navigation tree.

On this screen, you should make sure that there’s a valid email address, and a valid product name. Other fields are optional, and can provide your users more details about your product website, logo, terms and services, privacy policy, etc. The more information you provide here, the easier it is for your end users to identify and trust your application, and grant it the requested access.

Once you have provided the necessary information, save and close the page.

Creating OAuth2 Client ID

To create an OAuth2 clientId, you need to navigate to APIs & auth => Credentials option from the Project’s home page, and then click the Create new Client ID button.

Depending on your use case, you need to pick one of the following three configurations:

1. Native Application

• If you are an advertiser (or an agency) who manages your accounts using a single (or a few) Google accounts, you should normally go for this option regardless of whether your application is a web application or not.

  • In AdWords, this means you manage multiple accounts, all linked under a single (or a few) root MCC.
  • In DFP, this means you manage multiple Networks, all associated with a single (or a few) Google account.

• If you are an advertiser who is also a Google Apps user, and you manage Ads accounts only for users in your Google Apps domain, you may also consider the Service accounts option (see below).

• If you are a third-party application provider who manages accounts on behalf of other customers, and your application is native (e.g. Windows Form-based application), then you should consider this option.

  • In AdWords, this means you manage multiple accounts, which may all be standalone Advertiser accounts, or MCC hierarchies. You provide your users with a login screen where they can log in with their AdWords credentials and manage their AdWords accounts.
  • In DFP, this means you manage multiple Networks, which belongs to different Google accounts. You provide your users with a login screen where they can login using their DFP credentials, pick a Network and manage it.

The screen for creating a client ID for a native application is shown below:

Once you create your client ID, the client id and secret are available on the APIs & auth => Credentials page as shown below:

2. Web Application

If you are a third-party application provider who manages accounts on behalf of other customers, and your application is web-based, then you should consider this option.

• In AdWords, this means you manage multiple accounts, which may all be standalone Advertiser accounts, or MCC hierarchies. You provide your users with a login screen where they can log in with their AdWords credentials and manage their AdWords accounts.
• In DFP, this means you manage multiple Networks, which belongs to different Google accounts. You provide your users with a login screen where they can log in using their DFP credentials, pick a Network and manage it.

The screen for creating a client ID for a web application is shown below:

Once you create your client ID, the client id and secret are available on the APIs & auth => Credentials page as shown below:

One additional thing to keep in mind is that when implementing web flow, you need a valid redirect URL (OAuth2RedirectUri configuration key in App.config), which the Google servers will trigger once the user has granted permission to your application. This redirect URL should be registered on this page, under the REDIRECT URIs section. In this screenshot, I’ve added it as http://localhost:5000/OAuthLogin.aspx.

3. Service account

If you are an advertiser who

• Manages multiple AdWords accounts
• Also use Google Apps for Business
• All your AdWords accounts are associated with Google accounts in your Google Apps for Business domain (i.e. all accounts have their login email as [email protected] where domain.com is your Google Apps for Business domain).
• Doesn’t want to use Native application flow

then you can consider using a service account flow to access the various Ads APIs.

The screen for creating a client ID for a web application is shown below:

Once you create your client ID, Google Developers Console will download the certificate to your machine. You should set the value of OAuth2JwtCertificatePath configuration key in App.config as the location of this certificate in the local disk. The page also displays the certificate password; this value needs to be specified for the OAuth2JwtCertificatePassword configuration key in App.config).

Once you download the private key, you can close this dialog. The page also displays an Email address (OAuth2ServiceAccountEmail configuration key in App.config), which you need to note.