Passkey-Pflicht für die Google Ads API: Worauf sie sich bezieht und wie vergessene Autorisierungen zu finden sind

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. 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 – bis dahin hört also nichts auf zu funktionieren. Gefragt 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. Kein Repository verrät, 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, überstürzt die falsche Arbeit.

2. Festhalten, wer was autorisiert

Am Anfang steht das Artefakt, das fast niemand hat: eine schriftliche Matrix der eigenen Zugänge. Eine YAML-Datei im Repository ist ein Anfang, besser ist eine kleine SQLite-Tabelle, denn sie wird abgefragt werden. Wichtig sind genau die Spalten, die sich in sechs Monaten nicht mehr aus dem Gedächtnis rekonstruieren lassen.

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. Die vergessenen Autorisierungen finden

Ein Inventar ist nur so gut wie seine Abdeckung, und wehtun werden genau die vergessenen Einträge. Die Config-Bäume durchsuchen und das Ergebnis anschließend mit dem Notierten vergleichen.

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}")

Das Skript gehört auf jeden Host, der mit der API spricht – auch auf dem Analysten-Laptop, den niemand erwähnen möchte. Jede UNTRACKED-Zeile ist entweder eine im Inventar fehlende Zeile oder ein Credential, das heute zu widerrufen ist. Hinter jeder user_account-Zeile steht eine Person, die jetzt namentlich zu benennen ist.

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

Jetzt der operative Teil. Für jede user_account-Zeile gehört vorab festgelegt, was passiert, wenn diese Person nicht erreichbar ist – denn eine Anmeldung, die einen Passkey verlangt, verlangt auch den Menschen, der ihn besitzt.

1. Eine Vertretung benennen, die im Rahmen der eigenen Richtlinien Zugriff auf dasselbe Google-Konto hat, und sie in die Matrix eintragen.
2. Den Refresh Token aus persönlichen Dateien heraus in den Secret Store holen, damit die erneute Authentifizierung der einzige Schritt bleibt, für den es noch eine Person braucht.
3. Pro Integration notieren, welche Customer IDs keine Daten mehr liefern, wenn diese Autorisierung wegbricht. Das ist der Blast Radius, und er bestimmt die Reihenfolge der Arbeit.
4. Bei Agentur-Setups schriftlich festhalten, welche Seite die Autorisierung hält und wer an einem Freitagabend angerufen wird. Anschließend prüfen, 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;

Diese Abfrage gehört in einen vierteljährlichen Cronjob, der die Ausgabe per Mail verschickt. Eine leere Ergebnismenge ist das gesamte Review.

5. Fazit

Damit stehen drei kleine Dinge: 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 früher oder später jede API aufwirft, in deren Autorisierungskette ein Mensch steht.

Der Gewinn ist Ruhe. Bestehende Tokens funktionieren weiter, Service Accounts sind ausgenommen, der OAuth Client bleibt unangetastet, und die siebentägige Sperre, die in den Foren immer wieder wiederholt wird, steht überhaupt nicht in der Ankündigung. Das Original gehört gelesen, bevor irgendeine Zusammenfassung zur Handlungsgrundlage wird – auch dieser hier: Passkey authentication requirement for the Google Ads API. Und die gesparte Zeit gehört in die Zeilen der Matrix, in denen deputy noch leer ist.