Google Ads API będzie wymagać passkeys od sierpnia 2026

Google zacznie wymagać passkeys w procesie logowania do Google Ads API, który wydaje nowe dane uwierzytelniające, a wdrożenie zmiany rozpocznie się 5 sierpnia 2026 roku. Proces uwierzytelniania użytkownika, generujący nowe refresh tokeny OAuth 2.0, będzie musiał przejść wyzwanie passkey, a samo hasło oraz starsze metody dwuskładnikowe, takie jak kody SMS i jednorazowe hasła czasowe (TOTP), przestaną być akceptowane na tym etapie. Dla marek i agencji zarządzających Google Ads na dużą skalę za pomocą automatyzacji to twardy termin związany z bezpieczeństwem, a nie opcjonalna aktualizacja.

Co się stało

27 lipca 2026 roku Google Ads Developer Blog ogłosił, że „Google Ads API zacznie wymagać passkeys od użytkowników Google Ads API”. Wdrożenie ma się rozpocząć 5 sierpnia i objąć wszystkich użytkowników w ciągu kolejnych kilku tygodni.

Wymóg dotyczy procesu uwierzytelniania użytkownika, który tworzy nowe refresh tokeny OAuth 2.0. Istniejące refresh tokeny pozostają bez zmian: nadal działają, a integracje nie otrzymają prośby o ponowną autoryzację przy wymianie ich na access tokeny. Zmienia się sam akt autoryzacji nowego tokenu. Nowi użytkownicy zostaną poproszeni o zalogowanie się za pomocą passkey, a jeśli żaden nie istnieje, otrzymają prośbę o jego utworzenie. Google zaznacza również opóźnienie zaufania sięgające do siedmiu dni, zanim nowo utworzony passkey stanie się zaufany i gotowy do użycia, dlatego zaleca jego skonfigurowanie z wyprzedzeniem, a nie dopiero w chwili, gdy trzeba wydać token.

Zakres zmiany wykracza poza kod pisany bezpośrednio pod to API. Google wymienił Google Ads Editor, Google Ads scripts, BigQuery Data Transfer Service oraz konektory Data Studio jako narzędzia, które również zaczną wymagać uwierzytelniania opartego na passkeys.

Dlaczego to ważne

Hasła oraz jednorazowe kody z SMS-a lub aplikacji to dokładnie te elementy, na przechwycenie których nastawione są ataki phishingowe i przejęcia konta. Passkeys są odporne na phishing: są powiązane z konkretną, legalną stroną i nie da się ich wyłudzić ani powtórzyć tak, jak hasła czy jednorazowego kodu, dlatego ta zmiana zamyka dobrze znaną drogę do kont reklamowych, na których znajdują się budżety i dane klientów. Kompromis dotyczy strony operacyjnej: każdy zespół, który zautomatyzował generowanie tokenów w oparciu o założenie, że hasło plus jednorazowy kod wystarczą, ma teraz do czynienia z krokiem, którego skrypt nie wykona po cichu.

Co to oznacza dla marek wielolokalizacyjnych

Dla centralnego zespołu marketingu lub martech, który prowadzi kampanie Google Ads w setkach lub tysiącach lokalizacji, ryzykiem nie jest zablokowane logowanie, lecz ciche zatrzymanie automatyzacji. Zbiorcze przesyłanie danych przez Google Ads Editor, zaplanowane Google Ads scripts oraz transfery danych przez BigQuery Data Transfer Service opierają się na tym samym procesie tokenów, który się zmienia, a token, którego nie da się odnowić w sierpniu, zatrzymuje cały zasilany przez niego proces.

Praca do wykonania przed terminem to kwestia zarządzania, a nie klikania. Zrób inwentaryzację każdej integracji i konektora, który uruchamia proces uwierzytelniania użytkownika względem Google Ads API, bo to właśnie ten przepływ się zmienia; dostęp przez konto usługi (service account) korzysta z własnych danych uwierzytelniających i nie podlega temu wymogowi. Sprawdź, które tożsamości użytkowników wydają nowe refresh tokeny, i upewnij się, że przy każdej z nich zarejestrowany jest teraz zaufany passkey, uwzględniając siedmiodniowe opóźnienie zaufania. Zdecyduj, kto przechowuje passkeys dla kont współdzielonych lub zarządzanych zespołowo, i to udokumentuj, aby urządzenie jednego odchodzącego pracownika nie stało się powodem, dla którego cały krajowy portfel kampanii nie może się ponownie uwierzytelnić. Zaostrzenie dostępu do platform, które niosą Twoją obecność w sieci i dane reklamowe, to ta sama dyscyplina, która stoi za podejściem PinMeTo do ISO 27001 i rezydencji danych w UE: kontroluj, kto i co może mieć dostęp do kont, i miej na to dowód.

„Google Ads API zacznie wymagać passkeys od użytkowników Google Ads API”.

Google Ads Developer Blog

Podsumowanie

Istniejące automatyzacje nadal działają na swoich aktualnych refresh tokenach, a rutynowe odświeżanie access tokenów pozostaje bez zmian, więc 5 sierpnia samo w sobie niczego nie zepsuje. Ryzyko pojawia się w momencie, gdy każda integracja po raz pierwszy po wdrożeniu zmiany musi wydać nowy refresh token OAuth, bo to wtedy brakujący passkey zamienia się w zatrzymany proces. Marki, które zarządzają Google Ads i danymi swoich lokalizacji za pomocą PinMeTo API Suite i koordynują płatne działania lokalne dzięki lokalnym kampaniom reklamowym, powinny już teraz zarejestrować passkeys i przypisać za nie odpowiedzialność, zanim wdrożenie ruszy 5 sierpnia i w kolejnych tygodniach obejmie ich konta, oraz uwzględnić przy tym siedmiodniowe opóźnienie zaufania passkey.