Google Ads API verlangt jetzt Passkeys für neue Refresh Tokens

Wer schon einmal das Onboarding eines neuen Advertisers an einem Freitagabend automatisiert hat, weiß den Wert eines einzigen OAuth-Aufrufs, der einfach funktioniert. Dieser Aufruf bekommt jetzt einen Passkey-Schritt. Google verlangt künftig eine Passkey-Authentifizierung für jeden neuen OAuth 2.0 Refresh Token, der über die Google Ads API generiert wird – der stufenweise Rollout hat bereits begonnen.

Für Plattform-Engineers, die auf Google Ads aufbauen, ist das die Art von stillem API-Wechsel, der die Produktion am ersten Tag nicht bricht, aber zwei Monate später lautlos die nächste Client-Migration sabotiert. Der Umfang ist eng gefasst. Der Schadensradius, wenn man ihn ignoriert, ist es nicht.

Die wichtigsten Details

Die Anforderung, wie ALM Corp berichtete, wurde am 5. August 2026 verbindlich, mit einem stufenweisen Rollout, der in den darauffolgenden Wochen die Accounts erreicht. Jeder Nutzer, der dem Standard-OAuth-2.0-Flow folgt, um einen neuen Refresh Token für die Google Ads API zu erstellen, muss sich jetzt mit einem Passkey authentifizieren – anstatt mit Passwort und Zwei-Faktor-Code.

Die Mechanik ist unkompliziert. Passkeys verwenden kryptografische Schlüssel, wobei der private Schlüssel auf dem Gerät des Nutzers generiert und gespeichert wird. Hat ein Nutzer keinen Passkey konfiguriert, wird er zum Zeitpunkt der Authentifizierung zur Einrichtung gezwungen. Kein Passkey, kein Refresh Token.

Zwei Details sind wichtiger als die eigentliche Änderung.

Erstens: Bestehende Refresh Tokens sind sicher. Tokens, die vor dem 5. August erstellt wurden, funktionieren weiterhin. Dies ist kein Massenrückruf. Die Änderung greift nur, wenn jemand eine neue Integration startet, einen neuen Advertiser onboarded oder Zugangsdaten rotiert.

Zweitens: Es gibt ein sieben-tägiges Vertrauensverzögerungsfenster. Ein neu erstellter Passkey funktioniert zwar, gilt bei Google aber in der ersten Woche als nicht vertrauenswürdig. Google empfiehlt ausdrücklich, Passkeys im Voraus zu erstellen, um diese Karenzzeit ablaufen zu lassen, bevor man sich ernsthaft authentifizieren muss. Für Agenturen, die einen Kunden mit weniger als einer Woche Vorlaufzeit onboarden, ist das ein Planungsproblem im Gewand eines Sicherheitsfeatures.

Der Geltungsbereich geht über reine API-Aufrufe hinaus. Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service und Looker Studio sind alle betroffen. Auch Standardnutzer von Scripts und Looker Studio sind eingeschlossen – nicht nur Backend-Entwickler. Jede Integration, die ein Google Ads-Konto mit einer anderen Anwendung verbindet, wird letztendlich einen Passkey erfordern.

Die einzige saubere Ausnahme: Organisationen, die Service Accounts verwenden. Da Service Accounts nicht dem Standard-Benutzerauthentifizierungsflow folgen, liegen sie vollständig außerhalb dieser Anforderung. Dieser eine Satz ist die wichtigste Zeile in der Ankündigung für alle, die neue Integrationen von Grund auf aufbauen.

Warum das für Performance Marketing relevant ist

Jede Agentur, mit der ich im letzten Jahrzehnt gearbeitet habe, hat dasselbe Skelett im Schrank: ein gemeinsam genutztes Google-Konto, einen Refresh Token, der vor Jahren von jemandem erstellt wurde, der längst nicht mehr da ist, und einen Cron-Job, der jeden Morgen still Berichte abruft. Dieser Token funktioniert noch. In Ordnung. Aber in dem Moment, in dem man einen neuen Kunden onboarded, eine neue Sub-MCC-Integration startet oder zu einem neuen Reporting-Stack migriert, befindet man sich im neuen Regime.

Die operativen Auswirkungen lassen sich in drei Bereiche aufteilen. SaaS-Plattformen, die Google Ads-Management-Tools verkaufen, müssen ihre Onboarding-UX überarbeiten. Der alte Ablauf „hier klicken, mit Google einloggen, fertig" enthält jetzt einen Passkey-Bereitstellungsschritt für Nutzer, die noch keinen haben. Das ist keine große Aufgabe, aber es ist eine Support-Belastung. Erwarten Sie eine Flut von Tickets von Kunden, die nicht wissen, was ein Passkey ist, und nicht verstehen, warum ihr Yubikey nicht mehr so funktioniert wie früher ihr Passwort-Manager.

Agenturen, die neue Advertiser onboarden, sehen sich mit dem sieben-tägigen Vertrauensfenster als Planungseinschränkung konfrontiert. Wenn Ihr Standard-SLA lautet „Ihre Kampagnen werden innerhalb von 48 Stunden migriert", steht dieses Versprechen nun im Widerspruch zur Standardhaltung von Google. Meine Empfehlung: Agenturen sollten einen Passkey-Bereitstellungs-Checklistenpunkt in ihre Pre-Kickoff-Unterlagen aufnehmen, direkt neben der Abrechnungseinrichtung und dem Tracking-Pixel-Zugang.

Produktionsvorfälle, die ich bei ähnlichen Auth-Migrationen erlebt habe, folgen einem vorhersehbaren Muster. Etwas funktioniert in der Staging-Umgebung, weil Staging langlebige Tokens verwendet. Dann läuft ein Produktions-Token ab oder rotiert, der Re-Auth-Flow trifft auf die neue Anforderung, und das Reporting hört still auf zu funktionieren. Niemand bemerkt es, bis ein Kunde fragt, warum die Zahlen vom letzten Dienstag fehlen. Passkey-Rollouts sind besonders anfällig dafür, weil der Fehlermodus oft „Nutzer wird aufgefordert, Passkey in einem headless Kontext einzurichten" lautet – und das System einfach hängt.

Die unbequeme Schlussfolgerung: Wenn Ihre Plattform für headless Integrationen noch auf End-User-OAuth setzt, sagt Ihnen Google damit höflich, auf Service Accounts zu wechseln.

Auswirkungen auf die Branche

Für den breiteren Traffic- und Performance-Marketing-Stack ist dies ein Stupser, kein Stoß, in Richtung einer besser verteidigbaren Authentifizierungsposition. Passkeys sind objektiv bessere Sicherheit als Passwort plus TOTP. Der private Schlüssel verlässt das Gerät nie, Phishing-Resistenz ist eingebaut, und die Angriffsfläche für Credential Stuffing schrumpft. Niemand vernünftiges argumentiert gegen Passkeys als Grundprinzip.

Die Reibung liegt in der Infrastruktur. Ad-Tech-Anbieter, Bid Manager, Feed-Automatisierungstools, kanalübergreifende Reporting-Plattformen – sie alle haben ihr Onboarding in der Annahme aufgebaut, dass ein Mensch an einem Browser einen OAuth-Ablauf in einer Sitzung abschließen kann. Das sieben-tägige nicht vertrauenswürdige Fenster erzwingt ein zweiphasiges Onboarding: Zugangsdaten jetzt bereitstellen, Integration später aktivieren. Teams, die dies als UX-Redesign und nicht als Checkbox behandeln, werden die Nase vorn haben.

Es gibt auch einen Folgeeffekt für die BI-Schicht. Wenn Ihre Marketing-Analytics-Pipeline BigQuery Data Transfer Service verwendet, um Google Ads-Daten zu synchronisieren, und jemand diesen Transfer unter einem neuen Konto neu erstellt, stoßen sie auf die Passkey-Anforderung. Looker Studio-Dashboards, die Einzelpersonen statt Service Accounts gehören, befinden sich im selben Boot. Erwarten Sie, dass Finanz- und Analyseteams im nächsten Quartal verwirrte Tickets einreichen werden.

Das strategische Signal ist klar: Google standardisiert Passkeys auf seiner gesamten Entwickleroberfläche, und die Ads API ist ein großer früher Dominostein. Teams, die eine ordentliche Überprüfung des Secrets-Managements, eine Service-Account-Migration oder eine Auth-Provider-Konsolidierung aufgeschoben haben, haben jetzt eine treibende Kraft. Das ist gesund. Schmerzhaft, aber gesund.

Erwähnenswert für alle, die Multi-Plattform-Stacks jonglieren: Die Meta Marketing API hat ihr eigenes Auth-Modell mit System-Usern, das diese Art von Problem umgeht, und ist ein vernünftiger Referenzpunkt dafür, wie Service-Account-ähnliche Muster im Betrieb funktionieren.

Was zu beobachten ist

Drei Signale zeigen Ihnen, wie holprig das nächste Quartal wird.

Beobachten Sie, wie SaaS-Anbieter still ihre Onboarding-Dokumentation mit Passkey-Anleitungen aktualisieren. Die Anbieter, die innerhalb des ersten Monats des stufenweisen Rollouts klare Anleitungen liefern, sind diejenigen mit Engineering-Disziplin. Diejenigen, die im November noch Screenshots mit „Mit Google-Passwort einloggen" veröffentlichen, sollten Sie kritisch hinterfragen.

Beobachten Sie Ihren eigenen Token-Rotationskalender. Wenn Sie Refresh Tokens mit geplanter Rotation haben, prüfen Sie, ob die Rotation einen neuen Token-Grant auslöst oder den bestehenden wiederverwendet. Rotationsrichtlinien, die für die Zeit vor dem 5. August geschrieben wurden, könnten Sie jetzt unbeabsichtigt zum ungünstigsten Zeitpunkt in den Passkey-Flow ziehen.

Beobachten Sie eine Migrationswelle zu Service Accounts. Google hat End-User-OAuth für headless Workloads in operativen Begriffen effektiv teurer gemacht als Service-Account-Auth. Jedes Team, das noch ein menschliches Konto für Backend-Ads-API-Jobs verwendet, sollte „Migration zu Service Account" bis zum Quartalsende auf der Roadmap haben. Nicht weil der Himmel einstürzt, sondern weil die Alternative bedeutet, Ihrem CTO zu erklären, warum das Reporting wegen eines Passkey-Vertrauensfensters während einer Client-Demo abgestürzt ist.

Wichtige Erkenntnisse

• Nur neue Tokens: Bestehende OAuth Refresh Tokens, die vor dem 5. August 2026 erstellt wurden, funktionieren weiterhin. Panik ist nicht die richtige Reaktion, Planung schon.
• Die sieben-tägige Vertrauensverzögerung ist ein Planungsproblem: Erstellen Sie Passkeys mindestens eine Woche vor dem Onboarding eines neuen Advertisers oder einer neuen Integration.
• Service Accounts sind der Ausweg: Headless Workloads sollten von End-User-OAuth migrieren. Google hat Ihnen einen Grund gegeben – nutzen Sie ihn.
• Onboarding-UX muss überarbeitet werden: SaaS-Plattformen, die Google Ads-Konten im Auftrag von Kunden verwalten, müssen die Passkey-Bereitstellung in ihren Ablauf und ihre Support-Dokumentation integrieren.
• Der Geltungsbereich geht über die API hinaus: Google Ads Editor, Scripts, BigQuery Data Transfer und Looker Studio-Integrationen fallen alle unter dieselbe Anforderung. Prüfen Sie jede Oberfläche, nicht nur die offensichtliche.