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; die schrittweise Einführung 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.

Ein Passkey ist ein digitaler Anmeldenachweis, der meist per Fingerabdruck, Gesichtserkennung oder Geräte-PIN freigegeben wird. OAuth erlaubt einer Anwendung festgelegte Kontozugriffe. Der OAuth-Client bezeichnet die registrierte Anwendung. Ein Access-Token erlaubt API-Anfragen für begrenzte Zeit. Mit einem Refresh-Token kann die Anwendung ein weiteres Access-Token beziehen, ohne die vollständige Anmeldung zu wiederholen. Die API ist die Schnittstelle, über die Software Ads-Daten abruft oder verändert.

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 eine schrittweise Durchsetzung; aus dem Startdatum folgt kein belegter Aktivierungstermin für jedes einzelne Konto.

1. Drei unterschiedliche Wege zum Kontozugriff

• Neue Nutzerautorisierung: Sobald die Regel für das Konto greift, ist ein Passkey erforderlich. Passwort allein, SMS oder zeitbasierte Einmalcodes einer Authenticator-App (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: Ein Service Account ist ein Konto für Software statt für eine Person. Dieser Ablauf ist 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. Eine Zugangsliste ohne kopierte Geheimnisse

Für kleine Bestände genügt ein kontrolliert gepflegtes Dokument; SQLite, eine Datenbank in einer Datei, 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 genutzten Systemen erfasst die Liste außerdem die registrierte OAuth-Anwendung, ein gegebenenfalls übergeordnetes Ads-Verwaltungskonto und den Einsatz der Zugangsdaten im Test- oder Produktivbetrieb.

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. Zugangsdaten können stattdessen aus einem geschützten Speicher, aus Variablen beim Programmstart, einer abgeschotteten Softwareumgebung (Container), einem automatischen Bau- oder Bereitstellungsauftrag (CI) oder einer vom Anbieter verwalteten Verbindung kommen. Dabei entsteht möglicherweise keine passende lokale Datei.

Jeder Fund muss mit der Konfiguration der laufenden Software und der Zugangsliste abgeglichen werden. 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. Jede administrierende Person benötigt ein eigenes Konto mit erforderlichem Ads-Zugriff. Googles Ads-Hinweise raten von geteilten Identitäten ab; die Vertretung sollte keinen fremden Passkey übernehmen.
2. Bei nutzerautorisierten Integrationen hält die Dokumentation das freigebende Konto und den erlaubten Ablauf für eine erneute Freigabe fest. Ein Ersatz-Token eines anderen Kontos besitzt dessen Berechtigungen und muss gegen die benötigten Ads-Kontonummern (Customer IDs) geprüft werden.
3. Refresh-Tokens und Service-Zugangsdaten gehören in den vorgesehenen geschützten Zugangsdaten-Speicher. Eine Serverneuinstallation widerruft kein Token; verlorene Zugangsdaten können jedoch eine erneute Autorisierung erforderlich machen.
4. Für Aufgaben ohne anwesende Person kommen Service Accounts als zu prüfende Möglichkeit infrage. 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. Der Wiederherstellungsablauf benötigt eine regelmäßige Prüfung sowie eine erneute Kontrolle nach Änderungen an Personal, Berechtigungen, Zugangsdaten oder Systemen.

Die folgende 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.