Google is introducing a new security requirement for developers and platforms using the Google Ads API to generate OAuth 2.0 refresh tokens. Beginning in early August, any user making new tokens through the API must authenticate with a passkey during the OAuth 2.0 refresh token generation process. This update to the Google Ads developer ecosystem represents one of the most significant changes to the API in recent times.
The update is part of Google’s security initiative to better protect accounts. While it is unlikely to impact day-to-day advertisers, it can affect developers, agencies, and SaaS providers significantly. Any entity interacting with the Google Ads API on a technical level must prepare for this change in the future.
When The Rollout Begins
The requirement to use a passkey is set to become mandatory on August 5th. This date marks the beginning of a phased rollout to all users. Developers and companies utilizing the Google Ads API should prepare to see this update reach their accounts sometime in the weeks following August 5th. Any user following the standard user OAuth 2.0 authentication flow for the Google Ads API will be impacted at some point after this date.
Starting from the specified date, when creating new OAuth refresh tokens via the Google Ads API, a passkey will be necessary to ensure the authorization process. In other words, every person or organization that somehow utilizes the application programming interface (API) level of Google Ads on a regular basis will be affected by the changes described above.
What This Means for Developers
For the purpose of this update, passkeys take the place of passwords and two-step verification codes. The user that does not have a passkey set up will be compelled to do so at the time of authentication.
It goes without saying that the update depicted above is a major one. Simply put, Google is doing away with insecure authentication methods in favor of a proven secure alternative. As stated above, passkeys leverage cryptographic keys for security. They are used to increase the level of security, since a user’s private key is generated and stored only on their device, which means that the person does not need to type or verify any code since it is already present on their device. For platforms providing authentication services for their clients, this requires a change in the onboarding process to accommodate this additional step.
Existing vs. New OAuth Refresh Tokens
It is important to note that this change affects only new OAuth refresh tokens. Your existing OAuth refresh tokens created before this date will continue to work. This change should not affect your existing processes using Google Ads API. It primarily concerns authentication procedures beginning on or after the rollout date mentioned above. Essentially, this update becomes relevant when an entity sets up a new integration, including onboarding a new advertiser.
When creating a new authentication session, users will have to set up or provide a passkey as a means of granting access to their account. For the majority of users, this simply entails a brief additional step. For developers and platforms setting up client accounts, this entails an adjustment to the onboarding process.
The Seven Day Trust Period
One thing that users should be aware of is that a newly created passkey may take up to a week to gain full trust. This means that the passkey will be functional but Google will treat it as untrusted for the first week following its creation. Google recommends that entities creating a passkey ahead of time utilize this grace period to their advantage.
This note applies primarily to developers and platforms, as individual users are unlikely to have automated processes to onboard new advertisers. In the event that a company utilizes existing automation tools to set up a new advertiser in short notice, they should consider this potential delay when attempting to establish an integration. Agencies which set up advertisers on short notice should treat this update as a scheduling concern, not simply a technical one. Agencies setting up a new advertiser with less than a week’s notice before another passkey-dependent process begins should factor this delay into their planning.
Who Actually Needs To Prepare
As noted above, the vast majority of individuals using Google Ads through the standard interface will not be directly affected by this update. The changes concern primarily the use of the Google Ads API, which means that this update will primarily affect developers, agencies, and SaaS platforms that make regular use of Google Ads API in their work.
The majority of the impact falls on developers and platforms generating OAuth refresh tokens for Google Ads accounts. If a company utilizes the Google Ads API to access data, modify data, or analyze data, this update will eventually affect their onboarding process. These entities include developers, agencies, and platforms offering third-party software to analyze and interact with Google Ads data. Any integration that involves connecting a Google Ads account to another application will require a passkey to be set up at some point, unless otherwise stated below.
There is an exception to this rule, which concerns organizations utilizing service accounts for their operations. Since these entities do not utilize the standard user authentication process, this update does not affect them. For the majority of other entities, however, this update will require a slight modification to the onboarding process.
Other Google Ads Products Are Affected Too
The change in the authentication procedure also affects various Google Ads products which utilize the Google Ads API. Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service, and Looker Studio are among the various products which will be impacted by this update. Any user utilizing these products who does not have a passkey set up will be required to set one up, just like with the Google Ads API.
As such, the impact of this update extends beyond developers and agencies to include any user utilizing these products to access and interact with their Google Ads data. This includes standard users who utilize Google Ads Scripts or Looker Studio to modify or analyze their Google Ads data.
For the majority of users, this primarily affects their ability to utilize these tools in the future. For companies utilizing these tools, this update requires a minor adjustment to the onboarding process for any new users who utilize these tools. The same applies to third-party platforms interacting with the Google Ads API through these tools.
Why This Matters for Agencies and Other Entities
The changes outlined in this blog post will affect a large number of marketers. Therefore, agencies with multiple clients, SaaS companies using the Google Ads API, and customers of the BigQuery Data Transfer Service and/or Looker Studio need to be aware of the upcoming changes to their onboarding process.
This update, in particular, concerns entities that utilize an intermediary to access Google Ads data. Many companies utilizing the Google Ads API, including SaaS platforms offering Google Ads management services, offer their services to multiple clients. This update, therefore, concerns any organization that utilizes automation to access Google Ads data through the Google Ads API. For such organizations, the changes detailed in this update represent a minor update to the onboarding procedures for new clients or users.
The biggest concern for entities falling into this category is tied to timing. The update itself is unlikely to cause significant difficulties, as setting up a passkey only takes a brief period. A larger concern for agencies and other entities falls in the utilization of the seven-day trust period detailed above. An entity setting up a new user who has little time to authorize a new passkey before another process requiring Google Ads authorization commences runs the risk of encountering significant difficulties. For agencies billing retainer for clients whose onboarding processes are slowed down due to this update unexpectedly, this can be an especially troublesome concern.
Such entities should, therefore, prepare ahead of time to ensure that existing automation is set to accommodate this update. This update can be largely ignored for existing processes, as it only concerns processes involving a new OAuth refresh token being generated. Any entity frequently generating such tokens, however, should consider setting up a step in their onboarding process to create or request a passkey ahead of time, before the date outlined in this report.
Bottom Line
Beginning on August 5th, passkeys will become the standard means of authentication for anyone interacting with the Google Ads API to generate new OAuth 2.0 refresh tokens. This requirement will roll out to all users in the months following the start date. Developers, agencies, and other entities utilizing the Google Ads API should prepare new users for the updated sign-in procedure ahead of time, including accounting for the seven-day trust period in the event that they set up a new account or authorization procedure shortly before the date mentioned above.
FAQs
Q1: When will the passkey requirement for Google Ads API kick in?
It will start on August 5th, and Google will gradually apply the requirement to all users during the following weeks.
Q2: Will this apply to advertisers that login to Google Ads regularly?
No. Everyday advertisers that don’t use Google Ads API will not see any changes since the passkey requirement is tied directly to the authentication process for API developers.
Q3: Do the existing OAuth refresh tokens require reauthorization?
No. The existing OAuth refresh tokens will continue to work as before and will not require reauthorization. The requirement to generate a passkey applies only to the generation of new refresh tokens.
Q4: What kind of logins does passkey replace?
Passkeys will replace password-based single factor logins and two-factor authentications (SMS codes, time-based one-time password). Passkey will be generated in case a user does not possess one.
Q5: Is there a prompt that appears if a user does not have a passkey?
Yes, there will be prompts in case a user does not have a passkey. The user will be directed to create a passkey while generating a refresh token.
Q6: How long is the seven-day security delay for the passkeys?
If a passkey is generated recently, then it can be subject to the seven-day security delay, which means that the system won’t trust the newly created passkey for seven days. Teams that prepare passkeys in advance will not run into this issue during the onboarding of their users.
Q7: Does this affect other Google Ads tools?
Yes. Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service and Looker Studio all require authentication with Google Ads API, so their access requires users to generate passkeys.
Q8: Do applications with service accounts require passkeys?
No. Service accounts are not affected by the passkey requirement, since they are not going through user authentication.
Q9: Who needs to be prepared for this change?
Developers, agencies and SaaS platforms that generate OAuth refresh tokens for their users need to prepare their onboarding flow. Any team that manages client accounts through Google Ads API integrations and/or automation needs to be prepared.
Q10: What can teams do to avoid delays caused by the new requirement?
Google suggests creating a passkey in advance in order to avoid being hit with the seven-day trust delay. This way the delay will not appear at a bad time, such as during onboarding a new client account.
