{"id":65025,"date":"2026-07-28T07:34:26","date_gmt":"2026-07-28T11:34:26","guid":{"rendered":"https:\/\/overcentral.com\/en\/?p=65025"},"modified":"2026-07-28T07:34:26","modified_gmt":"2026-07-28T11:34:26","slug":"google-ads-api-passkeys-mandatory","status":"publish","type":"post","link":"https:\/\/overcentral.com\/en\/google-ads-api-passkeys-mandatory\/","title":{"rendered":"Google makes passkeys mandatory for Ads API users"},"content":{"rendered":"

Google has announced that passkeys will become the mandatory authentication method for users generating new OAuth 2.0 refresh tokens through the Google Ads API<\/a>, marking a decisive shift away from passwords and traditional two-factor codes. The change takes effect on August 5 and will roll out to all users over the following weeks. While existing integrations will continue to function without interruption, developers, agencies, and SaaS platforms that manage Google Ads accounts<\/a> programmatically must prepare for a fundamentally different sign-in experience\u2014one that relies on a user\u2019s device-bound cryptographic credential rather than a shared secret.<\/p>\n

What the new passkey requirement means for Google Ads API users<\/h2>\n

Under the updated authentication workflow, anyone who needs to generate a fresh OAuth 2.0 refresh token\u2014typically when onboarding a new advertiser or re-authorising an existing connection\u2014will be required to authenticate using a passkey. This replaces password-only login and all existing two-factor authentication methods, including SMS codes and time-based one-time passwords (TOTP). Users who have not yet created a passkey will be prompted to do so during the authentication flow.<\/p>\n

Google has also introduced a seven-day security delay for newly created passkeys. Until that trust period elapses, the passkey may not be fully accepted by the system. This delay is designed to protect accounts from credential theft: it gives the account owner time to detect and reverse an unauthorised passkey registration. Developers should factor this waiting period into their onboarding workflows to avoid unexpected authentication failures.<\/p>\n

Existing OAuth refresh tokens\u2014those already generated before the change\u2014will continue to work without requiring reauthorisation. The policy applies only to new token generation. Applications that use service accounts for automated, server-to-server workflows are not affected, since service accounts operate outside the user authentication flow.<\/p>\n

Why Google is pushing passkeys for the Ads API<\/h2>\n

Passkeys represent a fundamental evolution in authentication. Instead of a password that can be guessed, phished, or leaked, a passkey is a cryptographic key pair stored securely on the user\u2019s device (phone, laptop, or security key). Authentication happens through a simple biometric or device PIN check, and the private key never leaves the device. This architecture eliminates entire categories of attack, including credential stuffing, phishing, and replay attacks.<\/p>\n

Google has been a leading advocate for passkeys across its consumer and enterprise products. The company began supporting passkeys for personal Google Accounts in 2022 and extended the technology to Workspace accounts in 2023. Now, by making passkeys a hard requirement for the Ads API token generation workflow, Google is applying the same security model to one of its most commercially sensitive ecosystems. Advertisers collectively spend tens of billions of dollars through Google Ads, and the API is the backbone for managing bids, budgets, keywords, and performance data at scale. Any compromise of an OAuth refresh token could give an attacker persistent, authorised access to a Google Ads account\u2014potentially without the legitimate owner\u2019s knowledge.<\/p>\n

The move also aligns with a broader industry trend. Apple, Microsoft, and the FIDO Alliance have all championed passkeys as the successor to passwords. Regulatory pressure, particularly from the European<\/a> Union\u2019s strong authentication requirements under PSD2 and GDPR\u2019s security-by-design principles, is pushing platforms to adopt phishing-resistant authentication. Google\u2019s decision to mandate passkeys for the Ads API is therefore both a security improvement and a step toward regulatory compliance for the many businesses that rely on the platform.<\/p>\n

Which products and workflows are affected<\/h2>\n

The passkey requirement extends beyond the core Google Ads API to any Google Ads product that relies on it for user authentication. The affected tools include Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service, and Looker Studio. All of these products use OAuth 2.0 flows to link a user\u2019s Google Ads account to an application or service. Once the rollout is complete, any attempt to connect one of these tools to a Google Ads account without a passkey will trigger a prompt to create one.<\/p>\n

For Google Ads Editor, which many agency teams use to make bulk changes offline, the change means that when a new user first signs in\u2014or when an existing user\u2019s token expires and needs refreshing\u2014they must authenticate with a passkey. Similarly, Google Ads Scripts, which run automated tasks from within the Google Ads interface, rely on authorisation tied to a user account. If a script tries to generate a new token for a user who lacks a passkey, the script will fail until the passkey is created.<\/p>\n

BigQuery Data Transfer Service users who pull Ads data into Google Cloud will also encounter the requirement when setting up or re-authorising a transfer. The same applies to Looker Studio data sources that connect to Google Ads. Organisations that manage dozens or hundreds of Google Ads accounts across these tools should audit their current authorisation setup and ensure that all account administrators have a passkey registered before the August start date.<\/p>\n

What is an OAuth 2.0 refresh token and why does it matter<\/h2>\n

To understand the impact of this change, it helps to understand the role of the OAuth 2.0 refresh token. When a user authorises an application to access their Google Ads account, the system issues two tokens: an access token (short-lived, typically lasting an hour) and a refresh token (long-lived, used to obtain new access tokens automatically). The refresh token is what allows SaaS platforms, agency dashboards, and automated scripts to maintain continuous access without asking the user to log in again every hour.<\/p>\n

Because refresh tokens persist indefinitely unless revoked, they are a high-value target. If a refresh token is stolen, the attacker can use it to obtain valid access tokens indefinitely. By requiring a passkey at the moment the refresh token is generated, Google ensures that the credential is created in a context where the user has proven possession of a trusted device. This significantly raises the bar for token theft, especially compared to workflows that rely on passwords or SMS codes, both of which are phishable.<\/p>\n

Practical steps for developers and agencies<\/h2>\n

For teams that manage Google Ads accounts programmatically, the most immediate action is to communicate the upcoming requirement to all users who may need to authorise new integrations after August 5. This includes clients onboarding to a managed service, new employees who will access automated reporting tools, and any partner accounts that require fresh OAuth tokens.<\/p>\n

Google recommends creating a passkey ahead of time to minimise friction. Users can register a passkey through their Google Account security settings\u2014either on the device they use for authentication or on a security key (such as a YubiKey) that supports the FIDO2 standard. Once registered, the passkey is available for use across Google services, including the Ads OAuth flow.<\/p>\n

Developers building SaaS platforms that initiate the OAuth flow on behalf of users should prepare for the possibility that the user\u2019s initial authentication attempt will fail if no passkey exists. The OAuth authorisation endpoint will redirect the user to a passkey creation page. The user must complete that step before the refresh token can be issued. The seven-day trust period means that even after creating a passkey, the token generation may be delayed or blocked for up to a week, depending on how Google enforces the delay. Testing with a few accounts during the rollout window is advisable to understand the exact behaviour.<\/p>\n

It is also worth noting that service accounts\u2014used for server-to-server automation without user interaction\u2014are exempt. If your workflow uses a service account with domain-wide delegation, no changes are required. However, any workflow that relies on end-user OAuth (the standard 3-legged OAuth flow) will eventually be subject to the passkey requirement.<\/p>\n

Comparing the new approach with previous authentication methods<\/h2>\n

Before this change, Google Ads API authentication typically required a password plus an optional second factor\u2014either an SMS code, a TOTP from an authenticator app, or a hardware security key. While security keys (which use the same FIDO2 standard as passkeys) have been supported for years, their adoption has been limited by friction: users had to purchase, configure, and carry a physical device. Passkeys eliminate that barrier by storing the private key on a device the user already owns, with the option to sync across devices via a password manager or cloud keychain.<\/p>\n

Compared to TOTP and SMS, passkeys offer dramatically stronger security. TOTP codes can be intercepted in real<\/a> time by phishing attacks that set up fake login pages. SMS codes are vulnerable to SIM-swapping and interception. Passkeys, by contrast, are bound to the origin domain\u2014the browser or app that requested authentication must match the domain for which the passkey was created, making phishing nearly impossible.<\/p>\n

The seven-day delay is an interesting compromise. It prevents an attacker who gains brief physical access to a user\u2019s device from immediately using that device to authorise a new token. But it also introduces operational overhead for legitimate users who need a new token quickly\u2014for example, when setting up a new account for a time-sensitive campaign. Agencies should pro-actively register passkeys for all their account managers well before any planned integration work.<\/p>\n

Strategic implications for the advertising technology ecosystem<\/h2>\n

Google\u2019s enforcement of passkey authentication for the Ads API has ripple effects that extend beyond individual user convenience. The advertising technology landscape is populated by dozens of third-party platforms\u2014bid management tools, reporting dashboards, analytics suites, and creative optimisation services\u2014that rely on OAuth tokens generated through user authentication flows. Each of these platforms will need to handle the new passkey requirement gracefully, or risk frustrating their customers with broken integrations.<\/p>\n

For platform operators, the change adds a new variable to the user onboarding experience. Previously, adding a new Google Ads account could be as simple as clicking \u201cauthorise\u201d and entering an email and password. Now, the user must have a passkey ready, and may need to wait a week before the token is fully trusted. Platforms that do not clearly communicate this requirement in their setup wizard may receive an influx of support tickets when the rollout reaches critical mass.<\/p>\n

At the same time, the change strengthens the overall security posture of the Google Ads ecosystem. Stolen OAuth tokens have been used to drain advertising budgets and redirect traffic to fraudulent sites. By tying token generation to a device-bound credential, Google makes it significantly harder for attackers to persist access after a breach. For advertisers concerned about account hijacking, this is a net positive.<\/p>\n

The move also puts pressure on other advertising platforms to adopt similar standards. Microsoft Advertising, Amazon Ads, Meta, and TikTok all offer APIs that rely on OAuth 2.0. If Google\u2019s passkey mandate reduces credential theft without noticeably harming user experience, competitors may follow suit\u2014especially as regulatory bodies increasingly view SMS and TOTP as insufficient for protecting sensitive financial accounts.<\/p>\n

How the passkey mandate affects different user groups<\/h2>\n

Agency teams and managed service providers<\/h3>\n

Agencies that manage multiple Google Ads accounts will need to ensure every employee who authorises a new integration has a passkey. For large teams, this means scheduling a brief session where each person registers a passkey through their Google Account. The seven-day delay means that if a new employee joins and needs immediate access to an API-connected tool, they must create the passkey at least one week in advance. Agencies should document this rule in their onboarding checklists.<\/p>\n

SaaS platforms and tool developers<\/h3>\n

Third-party platforms that offer Google Ads integration must update their authorisation flow to handle the passkey prompt gracefully. If the user\u2019s browser or device does not support passkeys (uncommon now, but still possible on some older systems), the platform should provide clear guidance. Additionally, the platform should warn users that a new passkey may have a trust delay, and advise them to authorise connections well before they need the data.<\/p>\n

Individual advertisers and freelancers<\/h3>\n

Advertisers who only manage their own accounts may notice the change the next time they need to re-authorise a tool like Google Ads Scripts or Looker Studio. For most, creating a passkey is a one-time step that takes under a minute. The main inconvenience is the week-long trust period, but since most users do not generate new tokens frequently, the impact should be minimal.<\/p>\n

Enterprises with automated workflows<\/h3>\n

Large enterprises that use service accounts for automated reporting will not be affected, since service accounts bypass the user authentication flow. However, any workflow that uses end-user OAuth\u2014for example, a custom dashboard that lets individual managers authorise their own accounts\u2014must comply. Enterprises should audit all OAuth client IDs within their Google Ads manager accounts to determine which ones rely on user tokens versus service accounts.<\/p>\n

Timeline and rollout details<\/h2>\n

The change begins on August 5. Google has indicated that the passkey requirement will be enabled for all users over a period of several weeks, meaning some accounts may see the requirement earlier than others. There will be no option to opt out. Users who do not have a passkey when required will be shown a prompt to create one directly within the authentication flow. The prompt is expected to appear in the browser or device-native UI, depending on the platform.<\/p>\n

Once a user has created a passkey, it becomes available for all Google services linked to that account, not just the Ads API. This means that users who already use a passkey for their Google Account will not need to do anything extra. The change only affects those who have not yet adopted passkey authentication.<\/p>\n

The seven-day security delay applies only to newly created passkeys. If a user already has a passkey that has been registered for more than seven days, it will be immediately trusted for token generation. Existing OAuth tokens remain valid regardless of the passkey status.<\/p>\n

Preparing for the transition: a checklist<\/h2>\n
    \n
  • Confirm that all user accounts that generate OAuth refresh tokens have a registered passkey. This includes accounts used for authorising Google Ads Editor, Scripts, BigQuery transfers, and Looker Studio connections.<\/li>\n
  • Create passkeys at least one week before any planned new token generation to account for the security delay.<\/li>\n
  • Update internal documentation and client onboarding guides to reflect the new requirement.<\/li>\n
  • Test the passkey authentication flow with a test Google Ads account and a test OAuth client to ensure the integration works as expected.<\/li>\n
  • Communicate with any third-party platform vendors that access your Google Ads data to confirm they are aware of the change and have updated their authorisation handling.<\/li>\n
  • Review which integrations use end-user OAuth (3-legged OAuth) versus service accounts. Only end-user OAuth is affected.<\/li>\n<\/ul>\n

    What has not changed<\/h2>\n

    Several key aspects remain unaffected. Existing OAuth refresh tokens do not need to be reauthorised. Service accounts continue to work without user authentication. The Google Ads API itself remains unchanged in terms of endpoints, quotas, and data models. The passkey requirement only affects the token generation step of the OAuth 2.0 user authentication workflow. Applications that have already generated a refresh token and are using it to obtain access tokens will continue to operate normally. The change also does not affect the Google Ads web interface or the Google Ads mobile app, which use different authentication flows.<\/p>\n

    Additionally, Google has not announced any plans to retire or deprecate existing OAuth tokens that were generated without a passkey. Those tokens will remain valid until they expire or are revoked by the user. This provides a gradual migration path: no one is forced to reauthorise existing connections.<\/p>\n

    However, when those tokens eventually need to be refreshed\u2014if the user revokes access, changes their password, or the token is rotated\u2014the new passkey requirement will apply. Over time, all user-authenticated integrations will come through the new flow as old tokens are naturally replaced.<\/p>\n

    Broader context: Google\u2019s passwordless strategy<\/h2>\n

    This move is part of Google\u2019s long-term effort to eliminate passwords across its product suite. In 2023, Google made passkeys the default sign-in method for personal Google Accounts. In 2024, it extended passkey support to Google Workspace, including business and education accounts. The Ads API requirement is the first time Google has mandated passkeys for a business-critical developer API. It signals that the company considers passkey technology mature enough to enforce in high-security environments.<\/p>\n

    For developers, this is a strong incentive to adopt passkey APIs in their own applications. Google provides a WebAuthn API (via the Credential Management API) and platform-specific APIs for Android and iOS that make passkey registration and authentication straightforward. As more services follow Google\u2019s lead, the developer ecosystem will need to become fluent in passkey integration.<\/p>\n

    From a user experience perspective, passkeys simplify login. A single biometric prompt replaces the need to remember a password and then enter a time-sensitive code. The friction of the initial setup is offset by the elimination of password resets and account recovery, which are among the most common and costly support issues for platforms.<\/p>\n

    Looking at the competitive landscape<\/h2>\n

    Other major advertising platforms have been slower to mandate passkeys. Microsoft Advertising supports passkeys for sign-in but has not yet required them for API authentication. Meta\u2019s advertising API still relies on standard OAuth with optional two-factor. Amazon Ads uses a similar model. Google\u2019s move could set a precedent that accelerates adoption across the industry. For advertisers and developers who work across multiple platforms, the fragmentation of authentication requirements presents a short-term challenge. But if the industry converges on passkeys as the standard, the long-term benefit will be a more secure and simpler ecosystem.<\/p>\n

    Regulatory changes also play a role. The European Banking Authority\u2019s strong customer authentication (SCA) requirements, while aimed at payments, are influencing how tech companies think about access to sensitive user data. Using a passkey\u2014a cryptographic key linked to a user\u2019s device\u2014satisfies the \u201cpossession\u201d factor much more securely than a hardware token or phone number. Google may be positioning itself ahead of future regulatory mandates that require phishing-resistant authentication for any system handling personal data.<\/p>\n

    Final practical guidance for anyone affected<\/h2>\n

    If you or your team generate new OAuth refresh tokens for Google Ads\u2014whether through an in-house script, a commercial SaaS platform, or a tool like Google Ads Editor\u2014the time to act is before August 5. Register a passkey on each account that will need to authorise new integrations. If possible, do this at least a week before you plan to generate any new tokens, to avoid the seven-day trust delay. If you operate a platform that handles OAuth flows for many users, update your documentation and in-app messages to guide users through the passkey creation process.<\/p>\n

    The change is not disruptive for the majority of Google Ads users who rarely need to refresh authorisation tokens. But for the developers, agencies, and technology providers who power the programmatic advertising ecosystem, it represents a meaningful shift in how identity is verified. Google has drawn a line: passwords and TOTP codes are no longer sufficient for generating new API credentials. Passkeys are now the baseline. The advertising industry should treat this not as an optional upgrade but as the new normal.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Google has announced that passkeys will become the mandatory authentication method for users generating new OAuth 2.0 refresh tokens through the Google Ads API, marking a decisive shift away from passwords and traditional two-factor codes. The change takes effect on August 5 and will roll out to all users over the following weeks. While existing […]<\/p>\n","protected":false},"author":7,"featured_media":90467,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/en\/65025.png","fifu_image_alt":"Google makes passkeys mandatory for Ads API users","footnotes":""},"categories":[31],"tags":[],"class_list":["post-65025","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technology"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/en\/65025.png","fifu_image_alt":"Google makes passkeys mandatory for Ads API users","fifu_redirection_url":"https:\/\/searchengineland.com\/google-publishes-new-google-ads-passkey-help-doc-470505","_links":{"self":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/65025","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/comments?post=65025"}],"version-history":[{"count":0,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/65025\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media\/90467"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media?parent=65025"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/categories?post=65025"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/tags?post=65025"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}