Google verlangt Passkeys für neue OAuth-Token der Ads API

KI-generiert
Twitter LinkedIn E-Mail
05.08.2026 46 mal gelesen 2 Kommentare

Google verlangt Passkeys für neue OAuth-Aktualisierungstoken der Google Ads API

Google führt für Entwickler und Plattformen, die die Google Ads API zur Erstellung von OAuth 2.0-Aktualisierungstoken verwenden, eine neue Sicherheitsanforderung ein. Ab dem 5. August müssen Nutzer während der Generierung neuer Token einen Passkey zur Authentifizierung verwenden, wobei die Einführung in den folgenden Wochen schrittweise auf alle Nutzer ausgeweitet wird.

Nach Angaben von ALM Corp betrifft die Änderung vor allem Entwickler, Agenturen und SaaS-Plattformen, die Google-Ads-Konten über die API mit anderen Anwendungen verbinden. Für Werbetreibende, die die Google Ads API nicht nutzen, ändert sich durch die neue Vorgabe nichts.

Passkeys ersetzen dabei passwortbasierte Ein-Faktor-Anmeldungen und Zwei-Faktor-Authentifizierungen wie SMS-Codes und zeitbasierte Einmalpasswörter. Der private Schlüssel wird ausschließlich auf dem Gerät des Nutzers generiert und gespeichert; wer noch keinen Passkey eingerichtet hat, wird während der Erstellung eines Aktualisierungstokens dazu aufgefordert.

Die neue Vorgabe gilt nur für neue OAuth-Aktualisierungstoken. Bereits vor dem Einführungsdatum erstellte Token funktionieren laut ALM Corp weiterhin und müssen nicht erneut autorisiert werden.

Besondere Bedeutung hat eine siebentägige Vertrauensfrist: Ein neu erstellter Passkey kann bis zu einer Woche lang als nicht vertrauenswürdig behandelt werden. Google empfiehlt Unternehmen deshalb, Passkeys im Voraus zu erstellen, damit beim Onboarding neuer Nutzer oder Werbekunden keine Verzögerungen entstehen.

Beginn der Passkey-Pflicht5. August
Schrittweise EinführungIn den folgenden Wochen
Vertrauensfrist für neue PasskeysSiebentägige Sicherheitsverzögerung
Betroffene TokenNeue OAuth-Aktualisierungstoken
Bestehende TokenFunktionieren weiterhin wie bisher

Die Änderung betrifft außerdem Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service und Looker Studio, sofern diese Produkte über die Google Ads API auf Daten zugreifen oder diese bearbeiten. Nutzer dieser Werkzeuge müssen für den Zugriff einen Passkey generieren, falls noch keiner eingerichtet wurde.

Eine Ausnahme bilden Anwendungen mit Dienstkonten. Da Dienstkonten keine Standard-Benutzerauthentifizierung durchlaufen, sind sie von der Passkey-Anforderung nicht betroffen.

Für Agenturen und Organisationen mit automatisierten Onboarding-Prozessen liegt die zentrale Herausforderung laut ALM Corp weniger in der Einrichtung des Passkeys als vielmehr in der zeitlichen Planung. Wer neue Kundenkonten kurzfristig einrichtet, sollte die siebentägige Vertrauensfrist berücksichtigen und die Passkey-Erstellung in den Onboarding-Prozess aufnehmen.

  • Entwickler sollten die Generierung neuer OAuth-Aktualisierungstoken prüfen.
  • Agenturen sollten die Passkey-Einrichtung beim Onboarding neuer Werbekunden einplanen.
  • SaaS-Plattformen sollten ihre Authentifizierungs- und Einrichtungsprozesse anpassen.
  • Teams sollten Passkeys im Voraus erstellen, um die siebentägige Vertrauensverzögerung zu vermeiden.
  • Organisationen mit Dienstkonten sind von der Anforderung nicht betroffen.

Infobox – ALM Corp: Ab dem 5. August ist ein Passkey für neue OAuth-2.0-Aktualisierungstoken der Google Ads API erforderlich. Bestehende Token bleiben gültig; relevant ist die Änderung vor allem für API-Nutzer, Entwickler, Agenturen, SaaS-Plattformen sowie Anwender von Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service und Looker Studio.

OpenAI führt Conversion Bidding und neue Kampagnentools für ChatGPT-Anzeigen ein

Die zweite Meldung im Pressespiegel kündigt neue Funktionen für ChatGPT-Anzeigen an. Der bereitgestellte Quelltext enthält jedoch keine nutzbaren Informationen zum angekündigten Conversion Bidding oder zu den neuen Kampagnentools.

Als Quelle ist ALM Corp angegeben. Weitere verwertbare Angaben zu Funktionen, Zeitpunkten, Verfügbarkeit, Zielgruppen, Leistungswerten oder technischen Voraussetzungen sind im übermittelten Inhalt nicht enthalten.

Infobox – ALM Corp: Zum angekündigten Conversion Bidding und den neuen Kampagnentools für ChatGPT-Anzeigen liegen im bereitgestellten Quelltext keine nutzbaren Fakten vor.

Quellen:

Hinweis zum Einsatz von Künstlicher Intelligenz auf dieser Webseite

Ihre Meinung zu diesem Artikel

Bitte geben Sie eine gültige E-Mail-Adresse ein.
Bitte geben Sie einen Kommentar ein.
Klingt erstmal sicherer, aber die 7 Tage vertrauensfrist sind schon ein bischen unpraktisch für Agenturen, die schnell neue Kunden anlegen müssen. Gut ist immerhin das die alten Token weiter laufen, sonst wär bestimmt bei vielen gleich alles kaput gegangen. Und bei Dienstkonten muss man wohl nix machen, wenn ich das richtig verstanden hab.
Dem bisherigen Kommentar zur Vertrauensfrist kann ich nur zustimmen, gerade für Agenturen dürfte das im Alltag wirklich der Knackpunkt sein. Was mir dabei noch fehlt, ist die Frage, wie man mit kurzfristigen Notfällen umgeht: Wenn ein Kunde plötzlich dringend angebunden werden muss oder ein bestehender Zugang aus irgendeinem Grund neu autorisiert werden muss, hilft „bitte sieben Tage vorher planen“ natürlich nur bedingt. Da sollten Agenturen vermutlich einen kleinen Pool an vorbereiteten, vertrauenswürdigen Passkeys beziehungsweise verantwortlichen Nutzerkonten haben, sonst steht im schlechtesten Moment alles.

Auch bei den genannten Tools wie Google Ads Editor, Scripts oder Looker Studio wird das vermutlich nicht jedem sofort auffallen. Viele Nutzer sehen ja nur, dass ein Bericht nicht mehr aktualisiert wird oder ein Script plötzlich nach einer zusätzlichen Anmeldung fragt. Eine klare Meldung direkt im jeweiligen Produkt wäre deshalb ziemlich wichtig. Technisch ist die Sicherheitsmaßnahme nachvollziehbar, aber in der Praxis landen solche Änderungen oft erstmal beim Kollegen, der „irgendwas mit Google“ macht.

Dass bestehende Token weiter funktionieren, ist immerhin eine vernünftige Übergangslösung. Wenn Google alle alten Verbindungen sofort gekappt hätte, wären wahrscheinlich deutlich mehr Systeme gleichzeitig ausgefallen. Trotzdem sollte man sich nicht darauf verlassen, dass diese Ausnahme ewig bestehen bleibt. Unternehmen sollten jetzt wohl dokumentieren, welche Token wo eingesetzt werden und wer sie erstellt hat. Gerade bei alten Integrationen weiß sonst nach ein paar Jahren keiner mehr, ob der Zugang noch gebraucht wird oder an welchem Konto er hängt.

Die Ausnahme für Dienstkonten klingt ebenfalls sinnvoll, weil dort ja keine normale Nutzeranmeldung stattfindet. Allerdings dürfte genau das auch für Verwirrung sorgen: Manche Teams werden denken, sie seien komplett aus dem Thema raus, obwohl sie zusätzlich noch persönliche OAuth-Verbindungen oder Tools von einzelnen Mitarbeitern nutzen. Eine saubere Trennung zwischen Dienstkonto und Benutzerkonto ist hier wahrscheinlich wichtiger, als es auf den ersten Blick aussieht.

Und noch ein Punkt zu Passkeys allgemein: Die sind sicherer und meist angenehmer als SMS-Codes, aber Unternehmen müssen trotzdem klären, was bei Geräteverlust, Mitarbeiterwechsel oder Urlaub der zuständigen Person passiert. Wenn der einzige Passkey auf einem privaten Smartphone liegt, ist das keine besonders gute Firmenlösung. Ein zweiter Wiederherstellungsweg und klare Zuständigkeiten sollten daher gleich mit eingeplant werden. Sonst ersetzt man am Ende nur ein Sicherheitsproblem durch ein Organisationsproblem.

Die zweite Meldung zu den ChatGPT-Anzeigen wirkt daneben tatsächlich eher wie ein Platzhalter, weil konkrete Informationen zu Funktionen und Startterminen fehlen. Für Leser wäre es hilfreicher, diese Meldung klar als unbestätigt oder noch nicht ausreichend belegt zu kennzeichnen, statt sie neben die ziemlich konkrete Google-Ankündigung zu stellen. Bei der Google-Änderung kann man wenigstens direkt ableiten, was zu tun ist. Bei OpenAI bleibt momentan eigentlich nur die Frage offen, wann und ob überhaupt weitere Details kommen.
Counter