Wymóg passkey w Google Ads API: czego dotyczy i jak znaleźć zapomniane autoryzacje

Google ogłosiło 27 lipca 2026 r. wymóg passkey dla Google Ads API; wdrażanie rozpoczęło się 5 sierpnia. Kluczowy jest dokładny moment zastosowania: na objętych kontach passkey jest wymagany w procesie autoryzacji użytkownika tworzącym nowy token odświeżania OAuth. Ogłoszenie nie wymaga wymiany klienta OAuth.

Istniejące tokeny odświeżania nie tracą ważności z powodu tej reguły. Zwykła wymiana ważnego tokena odświeżania na token dostępu nie wymaga ponownego potwierdzenia passkey. Nie jest to gwarancja bezterminowej ważności: cofnięcie dostępu, limity tokenów, brak aktywności lub inne zasady dostępu nadal mogą przerwać integrację. Aktualna dokumentacja bezpieczeństwa opisuje stopniowe wdrażanie; sama data rozpoczęcia nie potwierdza terminu aktywacji dla każdego konta.

1. Trzy różne sytuacje uwierzytelniania

• Nowa autoryzacja użytkownika: po objęciu konta regułą wymagany jest passkey. Samo hasło, SMS ani TOTP nie zastępują tego potwierdzenia.
• Istniejący token odświeżania: reguła nie wymusza ponownej autoryzacji tylko w celu uzyskania kolejnego tokena dostępu.
• Proces konta usługi: nie jest objęty tym konkretnym wymogiem. Google zaleca ten proces dla odpowiednich zadań automatycznych lub offline. Nadal potrzebne są uprawnienia konta i ochrona poświadczeń.

Nowy passkey może podlegać siedmiodniowemu okresowi uzyskiwania zaufania. Nie oznacza to ogólnej blokady konta ani odrębnego siedmiodniowego czasu ważności tokena odświeżania zewnętrznej aplikacji OAuth w statusie Testing. Plan odtworzenia dostępu musi uwzględniać rzeczywisty sposób logowania i zasady konta.

2. Inwentaryzacja dostępów bez kopiowania sekretów

Przy niewielkim zbiorze wystarczy dokument z kontrolą dostępu; SQLite ułatwia powtarzalne zapytania. Poniższy przykład przechowuje tożsamości, odpowiedzialność i odwołania. Wartości tokenów, klucze prywatne i kody odzyskiwania nie powinny trafiać do tej tabeli ani repozytorium. Wiersz konta usługi powinien zawierać rzeczywisty adres e-mail tego konta zamiast pustej tożsamości.

CREATE TABLE ads_authorization (
  integration TEXT PRIMARY KEY NOT NULL,
  auth_type TEXT NOT NULL CHECK (auth_type IN
    ('user_account', 'service_account', 'unknown')),
  principal TEXT,
  config_path TEXT,
  token_store_reference TEXT,
  owner TEXT NOT NULL,
  deputy TEXT,
  recovery_plan_reference TEXT,
  customer_ids TEXT,
  last_verified TEXT
);

-- Illustrative metadata only; never insert tokens or private keys.
INSERT INTO ads_authorization VALUES
 ('nightly-cost-load', 'user_account', 'analyst@example.com',
  '/srv/adops/config/ads.yaml', 'vault:kv/ads/refresh',
  'analytics-team', 'platform-team', 'runbook:ads-reauthorization',
  '1234567890', NULL);

owner określa odpowiedzialność operacyjną. deputy wskazuje drugą odpowiedzialną osobę lub zespół, a nie zgodę na współdzielenie osobistej tożsamości Google. recovery_plan_reference prowadzi do przetestowanej procedury: przykładowo ponownej autoryzacji przez osobno uprawnione konto z odpowiednim dostępem Ads i kontrolowanej zmiany poświadczeń. Przy współdzielonej infrastrukturze inwentaryzacja wymaga także klienta OAuth, relacji konta menedżera i środowiska poświadczeń.

3. Wyszukiwanie wskazówek bez wyświetlania poświadczeń

Przeszukanie ograniczonego zakresu plików może ujawnić brakujące wpisy. Poniższe polecenie GNU grep wypisuje wyłącznie nazwy plików i uwzględnia typowe klucze JSON w cudzysłowach, zapis camelCase oraz nazwy zmiennych środowiskowych. Katalog jest przykładem wymagającym zastąpienia przez jawnie zatwierdzony zakres konfiguracji.

# Only an explicitly approved configuration directory; filenames only.
grep -rIlEi \
  --include='*.yaml' --include='*.yml' --include='*.json' \
  --include='*.env' --include='*.ini' --include='*.properties' \
  -- 'refresh[_-]?token|service_account|private_key_id|json_key_file_path|jsonKeyFilePath|serviceAccountSecretsPath' \
  /srv/adops/config

Kod wyjścia 0 oznacza trafienia, 1 brak trafień, a 2 błąd. Błędy uprawnień muszą pozostać widoczne. Trafienie nie potwierdza aktywnej autoryzacji Google Ads: komentarze, przykłady, inne API i nieaktualne pliki mogą zawierać te same terminy. Brak trafień również nie dowodzi kompletności. Odwołania do magazynu sekretów, zmienne uruchomieniowe, kontenery, zadania CI i zarządzane konektory mogą nie pozostawiać pasującego pliku lokalnego.

Każde trafienie wymaga porównania z konfiguracją wdrożenia i inwentaryzacją. Natychmiastowe unieważnienie nieznanego poświadczenia może przerwać zależność produkcyjną. Najpierw potrzebne jest ustalenie odpowiedzialności, rzeczywistego użycia oraz planu zastąpienia lub wycofania; podejrzenie przejęcia poświadczeń wymaga właściwej procedury incydentowej.

4. Odtworzenie dostępu z oddzielnymi tożsamościami

1. Każdej osobie administrującej zapewnić indywidualne konto z wymaganym dostępem Ads. Wskazówki Google Ads odradzają współdzielone tożsamości; zastępstwo nie powinno polegać na przejęciu cudzego passkey.
2. Dla integracji autoryzowanych przez użytkownika udokumentować konto i dozwoloną ścieżkę ponownej autoryzacji. Token innego konta ma uprawnienia tego konta i wymaga sprawdzenia wobec potrzebnych customer IDs.
3. Chronić tokeny odświeżania i poświadczenia usług w zatwierdzonym magazynie sekretów. Przebudowa serwera sama nie unieważnia tokena, lecz utrata poświadczenia może wymusić ponowną autoryzację.
4. Ocenić konta usług dla zadań bez nadzoru. Potrzebny jest jawny dostęp Ads oraz wymagana konfiguracja API; zmiana tożsamości nie sprowadza się do zmiany nazwy pliku. Przy dostępie przez konto menedżera może być wymagane login-customer-id.
5. Sprawdzać procedurę odtworzenia po zmianach kadrowych, uprawnień, poświadczeń lub infrastruktury oraz w regularnym cyklu kontroli.

Poniższe zapytanie SQLite wskazuje niepełne lub nieaktualne wpisy zarówno kont użytkowników, jak i kont usług. Okres 90 dni jest przykładową regułą operacyjną, a nie terminem Google. Daty powinny mieć zweryfikowany format YYYY-MM-DD; nieznany termin ostatniej kontroli musi pozostawać widoczny.

SELECT integration, auth_type, principal, owner, customer_ids
FROM ads_authorization
WHERE auth_type = 'unknown'
   OR NULLIF(TRIM(principal), '') IS NULL
   OR NULLIF(TRIM(deputy), '') IS NULL
   OR NULLIF(TRIM(recovery_plan_reference), '') IS NULL
   OR date(last_verified) IS NULL
   OR date(last_verified, '+0 days') <> last_verified
   OR date(last_verified) > date('now')
   OR date(last_verified) < date('now', '-90 days')
ORDER BY owner, integration;

Pusty wynik oznacza wyłącznie spełnienie tych zapisanych kryteriów. Nie dowodzi kompletności spisu, działania passkey ani wystarczających uprawnień Ads. Oddzielne dowody zapewniają kontrolowana próba dostępu tylko do odczytu i udokumentowana kontrola odtworzenia.