AuthorizationError.TWO_STEP_VERIFICATION_NOT_ENROLLED
AUTHENTICATION_FAILED
Understanding some of the finer details of DFP's OAuth2 flows can come in handy when the unexpected happens.
All DFP API requests are authenticated using access tokens. You can think of these as short-lived (about one hour) passwords. When making a request, you include the access token in the HTTP header:
Authorization: Bearer ACCESS_TOKEN
Every access token is tied to a specific user and one or more API scopes. The scopes control which Google APIs the access token is valid for. The scope for DFP is:
https://www.googleapis.com/auth/dfp
When authenticating as a dedicated API user like a service account, make sure that user is configured with your desired teams and role in DFP. There's no requirement that API users have administrator access.
POST https://www.googleapis.com/oauth2/v2/tokeninfo?access_token=MY_ACCESS_TOKEN { "issued_to": "1234567890-aabbccddgh123.apps.googleusercontent.com", "audience": "1234567890-aabbccddgh123.apps.googleusercontent.com", "scope": "https://www.googleapis.com/auth/dfp", "expires_in": 3496, "access_type": "offline" }
If your refresh token stops working, there are a few possible causes:
The simplest solution to all of these is to create a new client and generate a new refresh token for a current DFP user. Remember that the refresh token is tied to the account that authorizes the application, and not the user who created the OAuth2 client. When accepting the OAuth2 authorization prompt, verify that the user in the top right corner that is logged in is correct:
If OAuth2 still gives you a headache, we're happy to troubleshoot with you. Just reach out to us on our developer forum.
- Chris Seeley, DFP API Team
In the past, we’ve thrown AUTHENTICATION_FAILED errors as API exceptions whenever an OAuth2 access token was invalid, expired, or missing. Starting on the release date of v201608, the DFP API will reject these requests as HTTP 401 errors (unauthorized access) instead of as API exceptions for all versions.
If you really break it down, this is a win-win for everyone involved. You don’t waste application quota on authentication requests that are already going to fail, and we can focus on doing what we do best, responding to valid API requests.
What does this mean for you? That’s a bit trickier. If you’re catching the old authentication errors raised by our client libraries, then you’re going to want to shift your integration to catching HTTP errors instead. Since our client libraries are implemented with language-specific practices in mind, you’d be looking for these new occurrences to show up as either errors raised by the underlying HTTP or SOAP libraries or wrapped HTTP errors in the libraries themselves. These failures are generally deterministic and require user action - either to generate a new refresh token, to add a new API user, or to create a valid client - so this is mostly a shift in where to catch the exception rather than wrapping with retry logic.
As usual, if you have any questions or just want to talk about API things, let us know on the developer forum.
- Nicholas Chen, DFP API Team
The old DFP API OAuth2 scope has been deprecated. Any API requests using this scope after December 31, 2016 will fail authentication. OAuth2 requests must use the current DFP API scope (https://www.googleapis.com/auth/dfp) after that time.
If you use a service account to authenticate instead of a refresh token, verify that the scope you use to create credentials is: https://www.googleapis.com/auth/dfp.
If you're still unsure if this affects you, you can follow the steps below anyway with no negative impact.
If you're using a different OAuth2 authentication flow, consult the documentation for your scenario and identify where the scope is being set. If you need clarification, reach out on our developer forum for additional assistance.
adgroup_id
disapprovalReasons
Until now, the DFP API only supported the OAuth 2.0 native/installed application flow. The OAuth 2.0 service account flow was only supported it you had a Google Apps for Business Account. Today, we’re unveiling the new OAuth 2.0 service account flow for DFP. This authorization flow has been simplified to no longer require a Google Apps domain. We’ve also updated the DFP web UI to allow service accounts to be added to be a DFP network.
Service accounts allow access to Google APIs without the need for user interaction by authenticating solely with server-to-server interactions. Other OAuth 2.0 flows require user interaction or having an application cache a refresh token.
With the *.p12 key generated from the Google Developers Console and the service account added to the DFP network, you can now generate an OAuth 2.0 token. For example, using the Java client library:
GoogleCredential credential = new GoogleCredential.Builder() .setTransport(new NetHttpTransport()) .setJsonFactory(new GsonFactory()) .setServiceAccountId("****@developer.gserviceaccount.com") .setServiceAccountScopes("https://www.googleapis.com/auth/dfp") .setServiceAccountPrivateKeyFromP12File(new File("/path/to/key.p12")) .build();
For more information, see our updated guide on using service accounts with DFP.
- Vincent Tsao, DFP API Team
https://www.googleapis.com/auth/adwords
Whether you’re just starting out with the DoubleClick Ad Exchange Buyer REST API or are working with an unfamiliar client library, our examples will help you get started! Our examples are now on GitHub and have been expanded to cover the following languages:
Each of these include documentation to help you get started with the corresponding client library and demonstrate how you can use the Service Account authorization flow with the DoubleClick Ad Exchange Buyer REST API.
If you have any feedback or feature requests for these examples, we’d definitely be interested in hearing about it! Feel free to contact us via the forum or our Google+ page.
- Mark Saniscalchi, Ad Exchange Team
Is your AdWords API client application still using ClientLogin? If so, you should start your migration from ClientLogin to OAuth 2.0 as soon as possible.
Your AdWords API client applications must be fully migrated to OAuth 2.0 before ClientLogin is sunset in June 2014, as previously announced. If you don't migrate by then, your client applications will fail -- they won't be able to access your MCC account or any AdWords account via the API.
How do I get started?
We have prepared a ClientLogin to OAuth 2.0 migration guide which includes:
You don't want to worry about your applications failing, so get started now. For most developers with a single top level MCC, this migration will involve only a few configuration and code changes. But if you run into any issues with your particular application or AdWords accounts, you'll be glad you left plenty of time before the sunset to work things out.
We are here to help
If you run into any issues, or if you have any questions, please reach out to us on the AdWords API Forum.
- Ray Tsang, AdWords API Team
An authorization method is a scheme the client application uses to gain access to account information. AdWords, DoubleClick Ad Exchange Buyer and DFP APIs support several authorization methods including ClientLogin, OAuth1.0a and OAuth2.0. If you are still using an email address and a password to access the API, you are using the ClientLogin method which is now deprecated and is scheduled for sunset.
In a previous blog post we’ve covered general aspects of OAuth2.0 authorization and its benefits. To describe the process in more details, we’ve created a new article that shows how to use it with our official Ruby client library.
As always, please feel free to ask any questions regarding the client libraries or the AdWords API on our forum or during scheduled office hours. You can also follow the Google Ads Developer page for all Ads-related updates.
