Passkey-Pflicht für die Google Ads API: Geltungsbereich und vergessene Autorisierungen

Google kündigte am 27. Juli 2026 eine Passkey-Pflicht für die Google Ads API an; der Rollout begann am 5. August. Entscheidend ist der genaue Auslöser: Bei betroffenen Konten verlangt der Nutzer-Autorisierungsablauf zur Erzeugung eines neuen OAuth-Refresh-Tokens einen Passkey. Die Ankündigung fordert keinen Austausch des OAuth-Clients.

Bestehende Refresh-Tokens werden durch diese Regel nicht ungültig. Der gewöhnliche Austausch eines gültigen Refresh-Tokens gegen ein Access-Token verlangt keine erneute Passkey-Bestätigung. Eine unbegrenzte Gültigkeitszusage folgt daraus nicht: Widerruf, Token-Limits, Inaktivität oder andere Zugriffsregeln können Integrationen weiterhin unterbrechen. Die aktuelle Sicherheitsdokumentation beschreibt die Durchsetzung als Rollout; aus dem Startdatum folgt kein belegter Aktivierungstermin für jedes einzelne Konto.

1. Drei unterschiedliche Authentifizierungssituationen

• Neue Nutzerautorisierung: Sobald die Regel für das Konto greift, ist ein Passkey erforderlich. Passwort allein, SMS oder TOTP ersetzen diese Bestätigung nicht.
• Bestehendes Refresh-Token: Die Regel erzwingt keine erneute Autorisierung allein zum Bezug eines weiteren Access-Tokens.
• Service-Account-Ablauf: Von dieser konkreten Anforderung ausgenommen. Google empfiehlt diesen Ablauf für geeignete automatisierte oder Offline-Aufgaben. Kontoberechtigungen und Schutz der Zugangsdaten bleiben erforderlich.

Ein neuer Passkey kann einer siebentägigen Vertrauensfrist unterliegen. Das ist weder eine allgemeine Kontosperre noch die davon unabhängige siebentägige Refresh-Token-Laufzeit einer externen OAuth-App im Status Testing. Ein Wiederherstellungsplan muss den tatsächlichen Anmeldeweg und die Kontorichtlinien berücksichtigen.

2. Zugänge inventarisieren, keine Geheimnisse kopieren

Für kleine Bestände genügt ein kontrolliert gepflegtes Dokument; SQLite eignet sich für wiederkehrende Abfragen. Das folgende Beispiel speichert Identitäten, Zuständigkeiten und Verweise. Token-Werte, private Schlüssel und Wiederherstellungscodes gehören weder in diese Tabelle noch in ein Repository. Auch bei Service Accounts sollte die tatsächliche Konto-E-Mail statt einer leeren Identität erfasst werden.

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 bezeichnet die betriebliche Zuständigkeit. deputy nennt eine weitere zuständige Person oder ein Team, keine Erlaubnis zum Teilen einer persönlichen Google-Identität. recovery_plan_reference verweist auf einen getesteten Ablauf: beispielsweise erneute Autorisierung durch ein separat berechtigtes Nutzerkonto mit passendem Ads-Zugriff und anschließend kontrollierter Austausch der Zugangsdaten. Bei gemeinsam genutzter Infrastruktur gehören außerdem OAuth-Client, Verwaltungskontobeziehung und Zugangsdatenumgebung ins Inventar.

3. Konfigurationshinweise ohne Ausgabe von Zugangsdaten finden

Eine begrenzte Dateisuche kann fehlende Inventareinträge aufdecken. Der folgende GNU-grep-Befehl gibt ausschließlich Dateinamen aus und erfasst typische JSON-Schlüssel mit Anführungszeichen, camelCase-Schreibweisen und Umgebungsvariablen. Das Verzeichnis ist ein Beispiel und muss durch den ausdrücklich freigegebenen Konfigurationsbereich ersetzt werden.

# 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-Code 0 bedeutet Treffer, 1 keine Treffer und 2 einen Fehler. Zugriffsfehler müssen sichtbar bleiben. Ein Treffer belegt keine aktive Google-Ads-Autorisierung: Kommentare, Beispiele, andere APIs und veraltete Dateien können dieselben Begriffe enthalten. Auch ein leerer Suchlauf beweist keine Vollständigkeit. Secret-Manager-Verweise, Laufzeitvariablen, Container, CI-Jobs und verwaltete Konnektoren hinterlassen möglicherweise keine passende lokale Datei.

Jeder Fund benötigt den Abgleich mit Deployment-Konfiguration und Zugangsinventar. Der sofortige Widerruf unbekannter Zugangsdaten kann eine produktive Abhängigkeit unterbrechen. Zunächst gehören Zuständigkeit, tatsächliche Nutzung und Ersatz- oder Stilllegungsplan geklärt; bei Verdacht auf Kompromittierung greift der vorgesehene Vorfallprozess.

4. Wiederherstellung mit getrennten Identitäten planen

1. Für jede administrierende Person ein eigenes Konto mit erforderlichem Ads-Zugriff einrichten. Googles Ads-Hinweise raten von geteilten Identitäten ab; die Vertretung sollte keinen fremden Passkey übernehmen.
2. Bei nutzerautorisierten Integrationen das autorisierende Konto und einen zulässigen erneuten Autorisierungsweg dokumentieren. Ein Ersatz-Token eines anderen Kontos besitzt dessen Berechtigungen und muss gegen die benötigten Customer IDs geprüft werden.
3. Refresh-Tokens und Service-Zugangsdaten im vorgesehenen Secret Store schützen. Eine Serverneuinstallation widerruft kein Token; verlorene Zugangsdaten können jedoch eine erneute Autorisierung erforderlich machen.
4. Service Accounts für unbeaufsichtigte Aufgaben bewerten. Erforderlich sind ausdrücklicher Ads-Zugriff und die benötigte API-Konfiguration; ein Identitätswechsel besteht nicht nur im Austausch eines Dateinamens. Beim Zugriff über ein Verwaltungskonto kann login-customer-id erforderlich sein.
5. Den Wiederherstellungsablauf bei Personal-, Berechtigungs-, Zugangsdaten- oder Infrastrukturänderungen sowie in einem regelmäßigen Prüfturnus kontrollieren.

Die folgende SQLite-Abfrage listet unvollständige oder veraltete Einträge sowohl für Nutzerkonten als auch für Service Accounts. Die 90 Tage sind eine beispielhafte Betriebsregel, keine Google-Frist. Datumswerte werden im geprüften Format YYYY-MM-DD erwartet; unbekannte Prüftermine müssen sichtbar bleiben.

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;

Eine leere Ergebnismenge bedeutet lediglich, dass diese gespeicherten Prüfkriterien erfüllt sind. Vollständigkeit des Inventars, Funktionsfähigkeit eines Passkeys oder ausreichende Ads-Berechtigungen sind damit nicht belegt. Eine kontrollierte nur lesende Zugriffsprobe und eine dokumentierte Wiederherstellungsprüfung liefern dafür eigenständige Nachweise.