Problems migrating from ClientLogin to OAuth

104 views
Skip to first unread message

Derek M

unread,
Sep 4, 2015, 2:03:59 PM9/4/15
to AdWords API Forum
The last time I worked on AdWords API was about two years ago when ClientLogin was still supported for authorization. I see that no longer is the case now and I must move to using OAuth. I've been having a lot of trouble understanding how to do this.

I'm using server-side Javascript for this and cannot use any client libraries (didn't see any available for AdWords using Javascript anyways). I use Javascript to compose and parse the SOAP requests/responses.

Inside the guide it looks like I should just need to send a POST request to this URL with a few parameters (line breaks for readability):
https://accounts.google.com/o/oauth2/auth?
scope=email%20profile&
redirect_uri=http://localhost&
response_type=code&
client_id=149278968815.apps.googleusercontent.com

However, when I try to do this, I receive a 400 Error saying that "The redirect URI in the request: http://localhost did not match a registered redirect URI."

I have the Redirect URI set within the Developer Console > APIs & auth > Credentials > OAuth client IDs and in there it shows http://localhost for the authorized Redirect URI. The other option I could find in the guide uses some variation of urn:ietf:wg:oauth:2.0:oob , but when I try to set the Redirect URI within this section to that, I am unable to and receive this error "Invalid Redirect: urn:ietf:wg:oauth:2.0:oob must use either http or https as the scheme"

All I'm trying to do from this is get an offline token that does not expire for a while (refresh token I believe is the term) that I can then use within the AdWords API calls I need to make. Can someone help me with figuring out what I'm doing wrong here?

Anash P. Oommen (AdWords API Team)

unread,
Sep 4, 2015, 3:34:32 PM9/4/15
to AdWords API Forum
Hi Derek,

The simplest thing to do would be to use https://developers.google.com/oauthplayground/ to generate a refresh token and an access token. The scope to use is https://www.googleapis.com/auth/adwords.

Once you get the refresh token, it can be used to obtain an access token that expires every hour. Use the access token in the Authorization header to make API calls.

If you need the detailed logs, take a look at https://developers.google.com/identity/protocols/OAuth2WebServer?hl=en. Look at the offline flow that obtains a refresh token.

About urn:ietf:wg:oauth:2.0:oob: You can use that as a redirect URI iff the OAuth project type is marked as installed application. So you need to fix the project type in the Google Developer console.

I would also recommend https://github.com/googleads/googleads-dotnet-lib/wiki/How-to-create-OAuth2-client-id-and-secret as a guide. I think the UI is a bit dated, but the flow is unchanged.

Let me know if you need more help.

Cheers,
Anash P. Oommen,
AdWords API Advisor.

P.S: Just wondering, have you tried using AdWords Scripts? Does that work for you? https://developers.google.com/adwords/scripts/

Derek M

unread,
Sep 8, 2015, 2:09:19 PM9/8/15
to AdWords API Forum
Thanks for the assistance Anash. I had previously tried using the OAuth Playground but couldn't figure out how to make it work with AdWords since it wasn't in the list of available apps. I was able to generate the Refresh and Access token now when I input the scope you mentioned for AdWords. I'll let you know if I run into further issues with it.

As to AdWords Scripts I also use that. However, this was a scenario that I believe required using AdWords API. The situation is our CRM is NetSuite, which only allows server-side javascript for its custom coding. When certain changes to our items occur, I have custom coding that can do various things, and one of the ones I am trying to implement is so when I detect this certain change in NetSuite, it then calls out to AdWords API to make the change to the item's corresponding ad (deletes the old ad and creates a new ad with the new properties).

We're seeing if we can find a way to get our plan to work with AdWords Scripts as well. It's less efficient than the one proposed above, but should work fine.

Thanks again for all your help.
Reply all
Reply to author
Forward
0 new messages