Google Ads API Passkey Requirement: What It Applies To and How to Find Forgotten Authorizations

Google announced a passkey requirement for the Google Ads API on 27 July 2026, with rollout starting on 5 August. The precise trigger matters: affected accounts must use a passkey when the user authentication workflow generates a new OAuth refresh token. The announcement does not require replacement of the OAuth client.

A passkey is a digital sign-in credential, usually unlocked with a fingerprint, face scan or device PIN. OAuth lets an application receive defined account permissions. The OAuth client identifies the registered application. An access token authorizes API requests for a limited time; a refresh token lets the application request another access token without repeating the full user sign-in. The API is the interface through which software reads or changes Ads data.

Existing refresh tokens are not invalidated by this policy. Routine exchange of a valid refresh token for an access token does not require a new passkey challenge. This is not a lifetime guarantee: revocation, token limits, inactivity or other access policies can still interrupt an integration. The current security guide describes enforcement as a rollout, so an account-specific enforcement date cannot be inferred from the launch date alone.

1. Three different ways to prove account access

• New user authorization: passkey authentication is required when enforced for the account. A password alone, an SMS code or a time-based one-time code from an authenticator app (TOTP) cannot replace that challenge.
• Existing refresh token: the policy does not force reauthorization merely to obtain another access token.
• Service account workflow: a service account is an identity for software rather than a human user. This workflow is unaffected by this particular requirement. Google recommends this flow for suitable automated or offline workloads. Account permissions and credential protection still apply.

A newly created passkey may face a seven-day trust delay. This is neither a universal account lockout nor the separate seven-day refresh-token lifetime associated with an external OAuth app in Testing status. Recovery planning must account for the actual authentication method and account policy.

2. An access inventory without copied secrets

A small team can use a controlled document; SQLite, a database stored in a file, is useful when recurring queries are needed. The following example records identities, responsibilities and references. Token values, private keys and recovery codes do not belong in this table or a repository. A service-account row should identify the actual service-account email rather than leaving the principal empty.

CREATE TABLE ads_authorization (
  integration TEXT PRIMARY KEY NOT NULL,
  auth_type TEXT NOT NULL CHECK (auth_type IN
    ('user_account', 'service_account', 'unknown')),
  principal TEXT,
  config_path TEXT,
  token_store_reference TEXT,
  owner TEXT NOT NULL,
  deputy TEXT,
  recovery_plan_reference TEXT,
  customer_ids TEXT,
  last_verified TEXT
);

-- Illustrative metadata only; never insert tokens or private keys.
INSERT INTO ads_authorization VALUES
 ('nightly-cost-load', 'user_account', 'analyst@example.com',
  '/srv/adops/config/ads.yaml', 'vault:kv/ads/refresh',
  'analytics-team', 'platform-team', 'runbook:ads-reauthorization',
  '1234567890', NULL);

owner names the operational responsibility. deputy names a second responsible person or team, not permission to share a personal Google identity. recovery_plan_reference points to a tested procedure: for example, reauthorization by a separately authorized user with appropriate Ads access, followed by a controlled credential change. When several integrations share infrastructure, the inventory also records the registered OAuth application, any parent Ads manager account, and whether credentials belong to testing or production.

3. Finding configuration hints without printing credentials

A bounded file search can reveal missing inventory entries. The following GNU grep command prints filenames only and handles common quoted JSON keys, camelCase names and environment-variable names. The directory is an example and must be replaced with the explicitly approved configuration scope.

# Only an explicitly approved configuration directory; filenames only.
grep -rIlEi \
  --include='*.yaml' --include='*.yml' --include='*.json' \
  --include='*.env' --include='*.ini' --include='*.properties' \
  -- 'refresh[_-]?token|service_account|private_key_id|json_key_file_path|jsonKeyFilePath|serviceAccountSecretsPath' \
  /srv/adops/config

Exit 0 means matches, 1 means no matches, and 2 indicates an error. Permission errors must remain visible. A match does not establish an active Google Ads authorization: comments, examples, other APIs and obsolete files can contain the same terms. No match proves completeness either. Credentials may instead come from a protected secret store, variables supplied when a program starts, an isolated software container, an automated build or deployment job (CI), or a provider-managed connector. Those sources may leave no matching local file.

Each finding needs comparison with deployment configuration and the access inventory. Revoking an unknown credential immediately can break a production dependency. Ownership, actual use and a replacement or retirement plan should be established first; suspected compromise requires the applicable incident process.

4. Recovery planning with separate identities

1. Each human administrator needs an individual account with the required Ads access. Google’s Ads guidance discourages shared identities; a deputy should not borrow another account’s passkey.
2. For user-authorized integrations, the record identifies the authorizing account and an allowed procedure for granting access again. A replacement user’s token has that user’s permissions and must be tested against the required Ads account numbers (customer IDs).
3. Refresh tokens and service credentials belong in the approved protected credential store. A server rebuild does not itself revoke a token, but loss of the credential can require reauthorization.
4. Service accounts are an option to assess for jobs that run without a person present. The service account needs explicit Ads access and the integration’s required API configuration; changing the identity is not just replacing a filename. Access through a manager account may require login-customer-id.
5. The recovery procedure needs a check after changes in staffing, permissions, credentials or infrastructure, as well as on a regular review schedule.

The following query lists incomplete or outdated inventory records for both user and service accounts. The 90-day interval is an example operational policy, not a Google deadline. Dates are expected as validated YYYY-MM-DD values; unknown dates must remain visible.

SELECT integration, auth_type, principal, owner, customer_ids
FROM ads_authorization
WHERE auth_type = 'unknown'
   OR NULLIF(TRIM(principal), '') IS NULL
   OR NULLIF(TRIM(deputy), '') IS NULL
   OR NULLIF(TRIM(recovery_plan_reference), '') IS NULL
   OR date(last_verified) IS NULL
   OR date(last_verified, '+0 days') <> last_verified
   OR date(last_verified) > date('now')
   OR date(last_verified) < date('now', '-90 days')
ORDER BY owner, integration;

An empty result only means these stored checks passed. It does not prove that the inventory is complete, the passkey works, or Ads permissions remain sufficient. A controlled read-only access test and a documented recovery check provide separate evidence.