Hi everyone, welcome to another episode of
the Google Ads Developer Series on Authentication. I’m Laura, and I’m a Developer Relations
Engineer on the Google Ads API. In this episode, I’ll be demonstrating how
to set up a Cloud project to generate an OAuth client ID and client secret for a web application,
and then use the OAuth Playground to retrieve refresh and access tokens. OAuth2 credentials are needed to access the
Google Ads API regardless, but the process I’ll be showing you is most useful for users
who only need to access the accounts for a single manager account or Google Ads user. If you need to retrieve refresh tokens for
multiple users, stay tuned for a future episode on configuring client libraries for OAuth. Before we dive in, here’s an overview of
what we’ll be doing: First we’ll create a Google Cloud project. Then we’ll use our cloud project to generate
a client ID and client secret. Once we have those credentials, we’ll head
over to the OAuth Playground, which is a tool Google provides to manually generate API tokens. Once we have our tokens, we’ll run a code
example to test that we can successfully authenticate with OAuth. You can find instructions on how to do all
of this in the developer documentation, which I’ve also linked in the video description,
so reference that as an additional resource. I’ll walk step by step through the same
setup process and explain the gotchas along the way. We’ll start by creating a Google Cloud project
if we don’t already have one. So go to console.cloud.google.com. For demonstration purposes, we’re going
to create a new project. I’ll call this “My Project”, and I’ll
give it a location. The location is just the folder within my
organization where I want to store this project. Not all GCP accounts have Organizations; these
typically represent a company and are the root nodes in the Google Cloud resource hierarchy. Once I’ve selected my location, I’ll click
Create. We’ll wait for that project to become available
so that we can switch into it and create our credentials. Once we’ve switched into our project, we
need to head to APIs and Services, and then Credentials. You can see here, it’s giving us a warning
that we need to configure our OAuth Consent Screen. This is needed before we can actually set
up our client ID, so we’re going to do this first. There are some help articles available on
the right if you want to read more about what the Consent Screen is for, but in short, the
consent screen is shown to the user for whom this project will access the Google Ads API;
they must agree that your app can manage AdWords campaigns on your behalf. For my purposes, I’m going to select External
users as my user type. This means that my project will be available
to users outside of my Organization; if I were to select Internal users, I would be
limiting my app to authorization requests from members of my Organization. You’ll see the Consent Screen in practice
later on in the demo, when we use the OAuth playground to generate tokens. I’ll just call this “My App” and I’ll
give my email as the developer support. I don’t need any of these app domains for
my app, so I’ll move on to fill out my user contact email
with my own email. Scopes are the permissions our app will request
from the user, in our case we need to request permission to access the Google Ads API and
manage campaigns on behalf of the authenticating user. I actually don’t need to give any Scopes
right now, because I’m going to come back to this in the OAuth playground, so I’m
going to save and continue for now. This is just for demo purposes, so I won’t
add any test users either. This summary looks good, so I’ll head back
to my dashboard, and we’ll move on to our Credentials setup. So I click on Credentials again, then Create
Credentials, and we want to create an OAuth client ID. This, again, is one of the credentials that’s
necessary to access the Google Ads API. For this demo, we’ll be creating credentials
for a web application. Have a look at the Introduction episode of
the series for an explanation on when you might configure for a web application vs a
desktop application. These are the two different types of applications
you can use for the Google Ads API. We can leave Authorized JavaScript origins
blank because our app isn’t actually a client-side web application. Under Authorized Redirect URIs, which are
the endpoints that the OAuth 2.0 server will send responses to, we’ll need to put https://developers.google.com/oauthplayground. You can find this URL in the documentation
as well, it’s not something you need to know off the top of your head. So click create, and now we have our client
ID and secret. Let’s note these down so that we have them
easily accessible for the next piece, which is to use the OAuth playground to generate
our access and refresh tokens. Don’t worry if you’ve already exited out
without noting them down, since these will always be available to you through the console’s
Credentials page. If I go to “Download OAuth client”, you
can see them again. With our new credentials, we’ll head to
the OAuth Playground, using the link found in the description or in our developer docs,
which pre-populates some values for us. Now you can see it’s already populated some
of this configuration for us. In these settings in the corner, we want to
confirm a few things – first, make sure the “Use your own OAuth credentials” box
is checked; we’re good on that; we also need to make sure that our access type is
Offline, which it is. That makes it so that we get back a refresh
token and access token instead of just an access token. And we’ll also make sure that the OAuth
flow is set to Server-side. With all that checked out, we can plug in
our client ID and secret from before. So I’ll go back to the console and copy
those over. Now we want to select on the left side – this
is the scopes piece that I was referencing earlier. In our case, the scope that we need is this
AdWords scope, which is also pre-populated by that link. So we’ll click Authorize APIs, now that
we have all that set up, and it’s going to ask us to authenticate. This is the OAuth Consent Screen that we configured
earlier. Because I allowed external users, I could
also complete this step with a Google user outside of my Organization, and that would
generate access and refresh tokens for that user, which could be used alongside the client
ID and client secret we generated earlier. Alright, it wants to manage my AdWords campaigns;
I’ll allow this. Ok, no I have this authorization code, which
I can exchange for tokens. So I’ll click “Exchange authorization
code for tokens”. There we go. And it’s already giving a countdown for
when our access token will expire, but if we’re using the client libraries, we’ll
be able to use our refresh token to generate a new access token. If we’re using a client library, we can
copy that refresh token into the config file for our library, along with the client ID
and client secret values. We could also make a curl request by passing
the access token in the authorization header, but note that, as I mentioned, the refresh
tokens are long-lived, and the access tokens expire in an hour. For the purposes of this demo, we’ll be
testing our credentials using a client library, specifically the Python client library, but
every library requires the same configuration values, just differently formatted. Also note that in order for this to work,
a user with permissions on the advertiser or manager account should be used to generate
OAuth tokens. So in my case, the email that I used is on
the manager account of the accounts that I want to access. Alright, let's recap real quick. We first created a cloud project that enabled
the Google Ads API. Using the OAuth playground with the cloud
project's Client ID and client secret, we then created a refresh token. The refresh token authenticates us as a specific
user to a specific Ads account. We can repeat the refresh token generation
for another user on another account, using the same client ID and secret. That way one cloud project can manage many
Ads accounts. Alright, now with that all squared away, let’s
get straight into the demo. I’ve left some open spaces here for my client
ID, client secret, and refresh token. I’ll pull these directly from where I pasted
in the OAuth Playground. Now that I have those values set, I’m going
to go ahead and run one of my examples. So I’ve got all my credentials set up that
I just got from my new project, I have my developer token which I previously generated
through my manager account, and which doesn’t have to be generated through the same account
you used to generate the refresh token or the client ID and secret. Ok, well this is interesting. So we’re getting an error: permission denied,
because the API has not been used in that project before, or it is disabled; enable
it by visiting this URL. Let’s go back and plug that in. Alright, and now we’ve enabled the Google
Ads API. Let me go back and retry… And that worked! And that’s it! We’ve fully configured OAuth 2 for our web
app. Thanks everyone for joining!
