Google Ads API Passkeys: Ihr OAuth Client ist in Ordnung, Ihr Login nicht

Google hat die Passkey-Pflicht für den Zugriff auf die Google Ads API am 27.07.2026 angekündigt, der Rollout läuft seit dem 5. August. Seither taucht in jedem Team-Chat dieselbe Frage in immer neuen Varianten auf: „Müssen wir unseren OAuth Client neu ausstellen?” Nein, müssen Sie nicht. Die Anforderung betrifft die Art, wie sich der User Account hinter einer Autorisierung anmeldet. Der OAuth Client ist von dieser Änderung nicht betroffen, und bestehende Tokens bleiben gültig – während Sie das hier lesen, hört also nichts auf zu funktionieren. Was Sie brauchen, ist keine Panikmigration, sondern eine ehrliche Bestandsaufnahme: Welche Integrationen hängen daran, dass sich ein Mensch anmelden kann?

1. Der Login fällt darunter, der OAuth Client nicht

Die Unterscheidung ist schmal, und sie entscheidet alles Weitere. Wurde eine Integration von einer Person autorisiert, die sich mit ihrem eigenen Google-Konto durch einen Consent Screen geklickt hat, dann fällt die Anmeldung dieses Kontos unter die Passkey-Pflicht. Läuft sie über einen Service Account, dann nicht: Service Accounts sind ausgenommen. Gleiche API, gleiche Client Library, gleiche Customer IDs – der einzige Unterschied ist, wer sich authentifiziert hat.

Daraus folgen zwei Dinge. Kein Dashboard geht an einem festen Stichtag aus: Bestehende Tokens funktionieren weiter, der kritische Moment ist erst die nächste Anmeldung – etwa nachdem ein Token versehentlich widerrufen wurde oder eine Maschine neu aufgesetzt worden ist. Und das Risiko steckt in Personen, nicht im Code. Ihr Repository verrät Ihnen nicht, wer den Refresh Token besitzt.

Eine Richtigstellung, weil sie sich hartnäckig hält: Mehrere Beiträge behaupten, für betroffene Konten gebe es eine siebentägige Sperrfrist. Davon steht nichts in der Ankündigung. Diese Frist existiert nicht, und ein Migrationsplan, der darauf aufbaut, treibt Sie dazu, die falsche Arbeit zu überstürzen.

2. Halten Sie fest, wer was autorisiert

Beginnen Sie mit dem Artefakt, das fast niemand hat: einer schriftlichen Matrix Ihrer eigenen Zugänge. Eine YAML-Datei im Repository ist ein Anfang, besser ist eine kleine SQLite-Tabelle, denn Sie werden sie abfragen wollen. Wichtig sind genau die Spalten, die Sie in sechs Monaten nicht mehr aus dem Gedächtnis rekonstruieren können.

create table ads_authorization (
  integration     text primary key,
  auth_type       text not null check (auth_type in ('user_account','service_account')),
  google_account  text,
  config_path     text,
  token_store     text,
  owner           text not null,
  deputy          text,
  customer_ids    text,
  last_verified   date
);

insert into ads_authorization values
 ('nightly-cost-load','user_account','ads-bot@example.com','/srv/etl/conf/ads.yaml',
  'vault:kv/ads/refresh','l.wojcik','m.kowalski','123-456-7890,222-333-4444','2026-08-08'),
 ('bi-connector','service_account',null,'/srv/bi/sa.json',
  'gcp-secret-manager','platform-team',null,'123-456-7890','2026-08-08');

• auth_type: trennt den Bestand mit einer einzigen where-Klausel in betroffen und nicht betroffen.
• deputy: das Feld, um das es bei dieser Anforderung eigentlich geht. Wenn die Person in owner drei Wochen weg ist, wer meldet sich dann an?
• token_store: Ein persönliches Home-Verzeichnis ist hier ein Befund, kein Wert.

3. Finden Sie die Autorisierungen, die Sie vergessen haben

Ein Inventar ist nur so gut wie seine Abdeckung, und wehtun werden genau die Einträge, die Ihnen entfallen sind. Durchsuchen Sie die Config-Bäume und vergleichen Sie das Ergebnis anschließend mit dem, was Sie notiert haben.

grep -rIls -e refresh_token --include='*.y*ml' --include='*.json' --include='*.env' \
  /etc /srv /opt /home

#!/usr/bin/env python3
"""Lokale OAuth-Configs klassifizieren und mit dem Zugangsinventar abgleichen."""
import pathlib, re, sqlite3, sys

root = pathlib.Path(sys.argv[1])
patterns = ("*.yaml", "*.yml", "*.json", "*.env", "*.ini")
has_refresh = re.compile(r"refresh_token\s*[:=]\s*\S")
is_service = re.compile(r"service_account|private_key_id")

db = sqlite3.connect("access.db")
known = {row[0] for row in db.execute("select config_path from ads_authorization")}

for pattern in patterns:
    for path in sorted(root.rglob(pattern)):
        text = path.read_text(errors="ignore")
        if not (has_refresh.search(text) or is_service.search(text)):
            continue
        kind = "service_account" if is_service.search(text) else "user_account"
        flag = "" if str(path) in known else "  UNTRACKED"
        print(f"{kind:16}{path}{flag}")

Lassen Sie das Skript auf jedem Host laufen, der mit der API spricht – auch auf dem Analysten-Laptop, den niemand erwähnen möchte. Jede UNTRACKED-Zeile ist entweder eine Zeile, die Sie dem Inventar schulden, oder ein Credential, das Sie heute widerrufen sollten. Hinter jeder user_account-Zeile steht eine Person, die Sie jetzt namentlich benennen müssen.

4. Der Notfallpfad für geteilte Zugänge und Agenturzugänge

Jetzt der operative Teil. Legen Sie für jede user_account-Zeile vorab fest, was passiert, wenn diese Person nicht erreichbar ist – denn eine Anmeldung, die einen Passkey verlangt, verlangt auch den Menschen, der ihn besitzt.

1. Benennen Sie eine Vertretung, die im Rahmen Ihrer eigenen Richtlinien Zugriff auf dasselbe Google-Konto hat, und tragen Sie sie in die Matrix ein.
2. Holen Sie den Refresh Token aus persönlichen Dateien heraus in Ihren Secret Store, damit die erneute Authentifizierung der einzige Schritt bleibt, für den es noch eine Person braucht.
3. Notieren Sie pro Integration, welche Customer IDs keine Daten mehr liefern, wenn diese Autorisierung wegbricht. Das ist Ihr Blast Radius, und er bestimmt die Reihenfolge der Arbeit.
4. Halten Sie bei Agentur-Setups schriftlich fest, welche Seite die Autorisierung hält und wer an einem Freitagabend angerufen wird. Prüfen Sie anschließend, ob dort ein Service Account praktikabel ist, denn solche Zeilen fallen vollständig aus dem Geltungsbereich der Anforderung heraus.

select integration, google_account, owner, customer_ids
from ads_authorization
where auth_type = 'user_account'
  and (deputy is null or last_verified < date('now','-90 day'))
order by owner;

Packen Sie diese Abfrage in einen vierteljährlichen Cronjob und schicken Sie sich die Ausgabe per Mail. Eine leere Ergebnismenge ist das gesamte Review.

5. Fazit

Sie haben drei kleine Dinge gebaut: eine Tabelle, die festhält, welche Integration von welchem Konto autorisiert ist, einen Suchlauf, der die Konfigurationen findet, die niemand dokumentiert hat, und eine Abfrage, die jeden Single Point of Failure ohne Vertretung auflistet. Nichts davon ist auf Google beschränkt. Es beantwortet eine Frage, die Ihnen früher oder später jede API stellen wird, in deren Autorisierungskette ein Mensch steht.

Was Ihnen das einbringt, ist Ruhe. Bestehende Tokens funktionieren weiter, Service Accounts sind ausgenommen, Ihr OAuth Client bleibt unangetastet, und die siebentägige Sperre, die in den Foren immer wieder wiederholt wird, steht überhaupt nicht in der Ankündigung. Lesen Sie das Original, bevor Sie auf Grundlage irgendeiner Zusammenfassung handeln – auch dieser hier: Passkey authentication requirement for the Google Ads API. Und verwenden Sie die gesparte Zeit auf die Zeilen Ihrer Matrix, in denen deputy noch leer ist.