Najważniejsze wnioski w pigułce
Co się zmienia
- Google Ads API zacznie wymagać uwierzytelniania kluczami dostępu (passkeys) przy generowaniu nowych tokenów odświeżania OAuth 2.0
- Wdrożenie startuje 5 sierpnia 2026 i obejmie wszystkich użytkowników w ciągu kolejnych tygodni
- Hasło, kody TOTP i SMS-owe kody 2FA przestaną wystarczać do autoryzacji wrażliwych działań na koncie
Kogo to dotyczy
- Przepływ z kontem usługi (service account) — bez zmian, żadne działanie nie jest wymagane
- Przepływ uwierzytelniania użytkownika — nowi użytkownicy zostaną poproszeni o autoryzację kluczem dostępu
- Istniejące tokeny odświeżania OAuth działają dalej bez ponownej autoryzacji
Zmiana obejmie też narzędzia Google
- Google Ads Editor
- Google Ads scripts
- BigQuery Data Transfer Service
- Looker Studio (dawniej Data Studio) w połączeniu z Google Ads
Ryzyko operacyjne
- Nowy klucz dostępu może wymagać 7-dniowego okresu zaufania, zanim stanie się w pełni operacyjny
- Klucz warto utworzyć z wyprzedzeniem, a nie w dniu, w którym musisz odzyskać dostęp do API
Dlaczego Google zaostrza zasady uwierzytelniania
Konta Google Ads to jeden z najbardziej atrakcyjnych celów dla przestępców w całym ekosystemie reklamowym. Przejęcie dostępu oznacza natychmiastową możliwość drenowania budżetu, podmiany treści reklam i wyprowadzania danych o klientach. Google od dłuższego czasu systematycznie podnosi poprzeczkę w obszarze bezpieczeństwa i wymóg kluczy dostępu jest naturalną kontynuacją tego kierunku.
Kluczowa różnica polega na odporności na phishing. Kody TOTP z aplikacji uwierzytelniającej i hasła jednorazowe wysyłane SMS-em da się wyłudzić na fałszywej stronie logowania — atakujący przechwytuje kod i używa go w czasie rzeczywistym. Klucz dostępu jest kryptograficznie powiązany z domeną, dla której został utworzony, więc nie zadziała na podrobionej witrynie. To właśnie ta właściwość przesądziła o decyzji Google.
Dla agencji i zespołów in-house oznacza to jedno: bezpieczeństwo przestaje być opcją do odłożenia na później. Firmy, które zarządzają kilkudziesięcioma kontami klientów, muszą traktować tę zmianę jak projekt operacyjny z konkretnym terminem, a nie jak drobną informację techniczną z bloga dla programistów.
Co dokładnie się zmienia i od kiedy
Po wejściu zmiany w życie każdy użytkownik korzystający z przepływu uwierzytelniania użytkownika (user authentication workflow) do generowania nowych tokenów odświeżania OAuth 2.0 będzie musiał potwierdzić tożsamość kluczem dostępu. Jeśli nie masz jeszcze utworzonego klucza, system poprosi Cię o jego wygenerowanie i użycie do zakończenia procesu autoryzacji. Alternatywne metody — samo hasło, kody z aplikacji uwierzytelniającej czy kody SMS — zostaną w tym scenariuszu odrzucone.
Wdrożenie rozpocznie się 5 sierpnia 2026 i będzie stopniowo obejmowało wszystkich użytkowników w ciągu kolejnych tygodni. Warto zwrócić uwagę na to rozłożenie w czasie: brak monitu o klucz dostępu w pierwszych dniach nie oznacza, że Twoje konto zostało z tej zmiany wyłączone.
Istniejące tokeny odświeżania pozostają nietknięte. Będą działać tak jak dotychczas i nie zobaczysz prośby o ponowną autoryzację przy pobieraniu tokenów dostępu. Problem pojawia się dopiero w momencie, gdy token wygaśnie, zostanie unieważniony lub gdy będziesz podłączać nowego użytkownika czy nowe konto do integracji.
Konta usługi kontra przepływ użytkownika — praktyczna rekomendacja
Jeśli Twoja aplikacja korzysta z konta usługi (service account), ta zmiana Cię nie dotyczy i nie musisz podejmować żadnych działań. Google wprost zaleca ten model dla wszystkich integracji, które działają automatycznie lub w trybie offline — a to opisuje większość rozwiązań agencyjnych: harmonogramowane raporty, automatyczne aktualizacje stawek, synchronizację feedów produktowych czy panele klienckie zasilane danymi z API.
Migracja z przepływu użytkownika na konto usługi to inwestycja, która zwraca się w postaci przewidywalności. Integracja oparta na tokenie odświeżania konkretnej osoby jest krucha — wystarczy odejście pracownika, zmiana hasła czy unieważnienie tokenu i automatyzacja przestaje działać, często w najmniej odpowiednim momencie. Konto usługi eliminuje tę zależność od pojedynczego człowieka.
Jeśli natomiast Twoja aplikacja z założenia generuje tokeny odświeżania w imieniu użytkowników — na przykład jest to narzędzie SaaS, w którym klient podłącza własne konto reklamowe — musisz przygotować dokumentację i komunikację. Nowi użytkownicy napotkają wymóg klucza dostępu w trakcie onboardingu i warto, żeby wiedzieli o tym wcześniej niż w momencie zablokowania procesu.
Nie tylko API — Ads Editor, skrypty i BigQuery
Zmiana wykracza daleko poza integracje pisane samodzielnie. Produkty Google, które pod spodem korzystają z Google Ads API, również zaczną wymagać uwierzytelniania kluczem dostępu. Dotyczy to Google Ads Editor, skryptów Google Ads, usługi BigQuery Data Transfer Service oraz raportów w Looker Studio zasilanych danymi z Google Ads.
To rozszerzenie zakresu jest praktycznie najważniejszą częścią całej informacji. Specjalista, który nigdy nie napisał linijki kodu, ale codziennie pracuje w Ads Editorze albo utrzymuje kilkanaście skryptów automatyzujących budżety, zostanie objęty wymogiem dokładnie tak samo jak programista integrujący API. Jeśli nie masz włączonych kluczy dostępu, przy pierwszej próbie zobaczysz monit o ich dodanie.
W agencyjnej rzeczywistości oznacza to konieczność przeglądu wszystkich kont dostępowych w zespole — także tych technicznych, wspólnych i rzadko używanych. Konto, z którego raz na kwartał generujesz raport w Looker Studio, jest równie narażone na zablokowanie jak to używane codziennie.
7-dniowe opóźnienie: najważniejszy szczegół tej zmiany
Nowo utworzony klucz dostępu może podlegać 7-dniowemu opóźnieniu bezpieczeństwa, zanim zostanie uznany za zaufany i w pełni operacyjny. To mechanizm chroniący przed sytuacją, w której atakujący po przejęciu konta natychmiast dodaje własny klucz i przejmuje pełną kontrolę. Z perspektywy użytkownika to jednak tydzień, w którym możesz nie być w stanie wykonać krytycznej operacji.
Konsekwencja jest bardzo praktyczna: klucz trzeba utworzyć zawczasu, a nie w chwili, gdy właśnie wygasł token odświeżania przed comiesięcznym raportowaniem albo gdy trzeba pilnie zaciągnąć nowe konto klienta do systemu. Tworzenie klucza pod presją czasu to najgorszy możliwy scenariusz.
Konfiguracja jest prosta. Wejdź na g.co/passkeys, kliknij opcję utworzenia klucza dostępu, aby zalogować się do menedżera kluczy bezpieczeństwa, i wykonaj kroki wskazane przez Twoje urządzenie. Cały proces zajmuje kilka minut i można go powtórzyć dla każdego urządzenia oraz konta, z którego korzystasz.
Klucz sprzętowy jako rozwiązanie dla zespołów
Klucz dostępu zapisany w systemie urządzenia (telefonie, laptopie) działa dobrze w scenariuszu jednej osoby i jednego sprzętu. W praktyce agencyjnej ten model szybko się komplikuje — pracownik zmienia laptopa, telefon ulega awarii, a dostęp do konta technicznego musi mieć więcej niż jedna osoba w zespole.
Dlatego przy zarządzaniu wieloma kontami reklamowymi rekomenduję fizyczny klucz sprzętowy. Sprawdzonym wyborem jest Yubico YubiKey 5C NFC — obsługuje standard FIDO2/WebAuthn wymagany przez klucze dostępu Google, łączy się przez USB-C oraz NFC, więc działa zarówno z komputerem, jak i ze smartfonem. Klucz jest niezależny od konkretnego urządzenia: wymiana laptopa nie wymusza rekonfiguracji uwierzytelniania.
Dobra praktyka to posiadanie co najmniej dwóch kluczy — podstawowego, noszonego przy sobie, i zapasowego przechowywanego w bezpiecznym miejscu. Utrata jedynego klucza bez alternatywnej metody odzyskiwania dostępu bywa bardzo kosztowna w czasie. Ta sama zasada dotyczy zresztą wszystkich kluczowych systemów firmowych, nie tylko Google Ads.
Podsumowanie
Wymóg kluczy dostępu w Google Ads API to zmiana o dużym zasięgu operacyjnym — obejmie nie tylko integracje programistyczne, ale też Ads Editor, skrypty, BigQuery Data Transfer Service i Looker Studio. Kluczowe działanie do wykonania jest jedno i proste: utwórz klucz dostępu jeszcze przed 5 sierpnia 2026, żeby 7-dniowy okres zaufania nie zablokował Ci pracy w najgorszym momencie. Jeśli zarządzasz wieloma kontami, warto od razu przejść na klucz sprzętowy i zaplanować migrację automatyzacji na konta usługi.
Źródło: Google Ads Developer Blog, „Passkey authentication requirement for the Google Ads API”, 27 lipca 2026 — ads-developers.googleblog.com
