Google Ads API i passkeys: klient OAuth jest w porządku, logowanie już nie

Google ogłosiło wymóg stosowania passkeys przy dostępie do Google Ads API 27.07.2026, a wdrażanie ruszyło 5 sierpnia. Od tego czasu w każdym firmowym czacie wraca to samo pytanie w kolejnych wariantach: „czy musimy wystawić nowego klienta OAuth?”. Nie trzeba. Wymóg dotyczy sposobu, w jaki loguje się konto użytkownika stojące za autoryzacją. Klient OAuth nie jest przedmiotem tej zmiany, a istniejące tokeny pozostają ważne, więc w trakcie lektury tego tekstu nic nie przestanie działać. Potrzebna jest nie pospieszna migracja, lecz rzetelna inwentaryzacja tego, które integracje zależą od zdolności człowieka do zalogowania się.

1. Logowanie jest objęte wymogiem, klient OAuth nie

Rozróżnienie jest wąskie i to ono przesądza o całej reszcie. Jeżeli integrację autoryzowała osoba, która przeklikała ekran zgody własnym kontem Google, logowanie tego konta podlega wymogowi passkey. Jeżeli integracja działa przez service account, nie podlega: service accounts są wyłączone. To samo API, ta sama biblioteka kliencka, te same customer IDs; jedyna różnica polega na tym, kto się uwierzytelnił.

Wynikają z tego dwie rzeczy. Żaden dashboard nie zgaśnie w wyznaczonym dniu: istniejące tokeny nadal działają, więc punktem zapalnym jest dopiero moment, w którym ktoś będzie musiał zalogować się ponownie, po przypadkowym unieważnieniu tokena albo po przebudowie maszyny. Ryzyko leży zaś w ludziach, nie w kodzie. Repozytorium nie powie, kto trzyma refresh token.

Jedno sprostowanie, ponieważ ta teza wciąż krąży: część opracowań podaje, że dla objętych kont obowiązuje siedmiodniowy okres blokady. W ogłoszeniu nie ma o tym mowy. Taki termin nie istnieje, a plan migracji oparty na nim wymusi pośpiech przy niewłaściwych zadaniach.

2. Należy spisać, kto co autoryzuje

Punktem wyjścia jest artefakt, którego prawie nikt nie posiada: spisana macierz własnych dostępów. Plik YAML w repozytorium to początek, ale niewielka tabela SQLite sprawdzi się lepiej, ponieważ prędzej czy później pojawi się potrzeba jej odpytywania. Znaczenie mają te kolumny, których za pół roku nie da się odtworzyć z pamięci.

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: dzieli całe środowisko na objęte i nieobjęte wymogiem jedną klauzulą where.
• deputy: pole, o które w tym wymogu naprawdę chodzi. Jeżeli osoba wpisana w owner jest nieobecna przez trzy tygodnie, kto się zaloguje?
• token_store: prywatny katalog domowy nie jest tutaj wartością, lecz znaleziskiem audytowym.

3. Odnalezienie autoryzacji, o których wszyscy zapomnieli

Inwentaryzacja jest warta tyle, ile jej pokrycie, a najbardziej bolą właśnie te wpisy, o których się zapomniało. Trzeba przeczesać drzewa konfiguracji, a następnie zestawić wynik z tym, co zostało spisane.

grep -rIls -e refresh_token --include='*.y*ml' --include='*.json' --include='*.env' \
  /etc /srv /opt /home

#!/usr/bin/env python3
"""Klasyfikuje lokalne konfiguracje OAuth i zestawia je z inwentaryzacją dostępów."""
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}")

Skrypt należy uruchomić na każdym hoście, który komunikuje się z API, łącznie z laptopem analityka, o którym nikt nie chce wspominać. Każdy wiersz UNTRACKED to albo pozycja brakująca w inwentaryzacji, albo poświadczenie do unieważnienia jeszcze dzisiaj. Każdy wiersz user_account to osoba, którą trzeba teraz wskazać z imienia i nazwiska.

4. Ścieżka awaryjna dla dostępów współdzielonych i agencyjnych

Teraz część operacyjna. Dla każdego wiersza user_account trzeba z góry ustalić, co się dzieje, gdy dana osoba jest niedostępna, ponieważ logowanie wymagające passkey wymaga też człowieka, który ten passkey posiada.

1. Należy wskazać zastępcę z dostępem do tego samego konta Google, zgodnie z wewnętrzną polityką, i odnotować go w macierzy.
2. Refresh token trzeba przenieść z prywatnych plików do firmowego magazynu sekretów, tak aby ponowne uwierzytelnienie pozostało jedynym krokiem wymagającym udziału człowieka.
3. Dla każdej integracji warto odnotować, które customer IDs przestaną raportować, jeżeli dana autoryzacja przestanie działać. To jest promień rażenia i to on wyznacza kolejność prac.
4. W układach agencyjnych trzeba ustalić na piśmie, która strona trzyma autoryzację i do kogo dzwoni się w piątkowy wieczór. Następnie należy sprawdzić, czy da się tam zastosować service account, ponieważ takie wiersze wychodzą całkowicie poza zakres wymogu.

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;

To zapytanie warto umieścić w kwartalnym zadaniu cron i wysyłać jego wynik na własny adres e-mail. Pusty zbiór wyników to cały przegląd.

5. Podsumowanie

Powstały trzy niewielkie rzeczy: tabela zapisująca, która integracja jest autoryzowana przez które konto, przemiatanie konfiguracji odnajdujące to, czego nikt nie spisał, oraz zapytanie wypisujące każdy pojedynczy punkt awarii pozbawiony zastępcy. Nic z tego nie jest specyficzne dla Google. Odpowiada to na pytanie, które prędzej czy później zada każde API z człowiekiem w łańcuchu autoryzacji.

Zyskiem jest spokój. Istniejące tokeny nadal działają, service accounts są wyłączone, klient OAuth pozostaje nietknięty, a siedmiodniowej blokady, którą powtarzają fora, w ogłoszeniu w ogóle nie ma. Przed podjęciem działań na podstawie jakiegokolwiek streszczenia, również tego, należy sięgnąć do oryginału: Passkey authentication requirement for the Google Ads API. Zaoszczędzony czas najlepiej poświęcić tym wierszom macierzy, w których deputy wciąż pozostaje puste.