Article : How to create OAuth2 client id and secret

How to create OAuth2 client id and secret

Introduction

AdWords, DFP and DFA 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 Cloud Console. This wiki article walks you through the process of creating one.

Accessing the Google Cloud Console
The Google Cloud Console is available from https://cloud.google.com/console. 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 registering multiple applications.

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.

Registering an application
You need to register your application to obtain an OAuth2 client ID and secret (OAuth2ClientId and OAuth2ClientSecret configuration keys in App.config). To register an application, navigate to APIs & auth => Registered apps option from the Project’s home page, and then click the Register App 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.

You should pick this option even if your application is a web application.

•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.
•In DFA, this means you manage multiple Users, 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 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.
•In DFA, this means you manage multiple Users, which belongs to different Google accounts. You provide your users with a login screen where they can login using their Google Credentials, pick a User and then manage that DFA account.
The screens for registering a new Native application are given below.

Once you register your application, it is displayed on the Registered Apps page. To get the client ID and secret, view the App details by clicking the App name in the list. The App detail screen is 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.
•In DFA, this means you manage multiple Users, which belongs to different Google accounts. You provide your users with a login screen where they can log in using their Google Credentials, pick a User and then manage that DFA account.
The screens for registering a new web application are given below.

Once you register your application, it is displayed on the Registered Apps page. To get the client ID and secret, view the App details by clicking the App name in the list. The App detail screen is shown below:

Expand the OAuth 2.0 Client ID section to view your client ID and secret. The screen is 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 URI 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 user@domain.com 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.

To create a service account, you need to complete all the steps (minus the REDIRECT URI) in the web flow (above). Now expand the Certificate section, as shown below:

Now click the Generate Certificate button. This will bring up a dialog that allows you to download the certificate private key (OAuth2JwtCertificatePath configuration key in App.config is the path to this certificate file on your local disk). This dialog also displays a password that you need to take a note. (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. The client ID and secret are available by expanding the OAuth2 Client ID section on the screen.