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.

Passkey to cyfrowe poświadczenie logowania, zwykle odblokowywane odciskiem palca, rozpoznaniem twarzy lub kodem PIN urządzenia. OAuth pozwala przyznać aplikacji określony dostęp do konta. Klient OAuth oznacza zarejestrowaną aplikację. Token dostępu pozwala wysyłać żądania API przez ograniczony czas. Token odświeżania pozwala aplikacji uzyskać kolejny token dostępu bez powtarzania pełnego logowania. API to interfejs, przez który program odczytuje lub zmienia dane Ads.

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 sposoby potwierdzania dostępu do konta

• Nowa autoryzacja użytkownika: po objęciu konta regułą wymagany jest passkey. Samo hasło, SMS ani czasowe kody jednorazowe z aplikacji uwierzytelniającej (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: konto usługi jest tożsamością programu, a nie osoby. Ten proces 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, baza danych zapisana w pliku, 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ółdzielonych systemach spis obejmuje także zarejestrowaną aplikację OAuth, ewentualne nadrzędne konto menedżera Ads oraz informację, czy poświadczenia służą do testów, czy do pracy produkcyjnej.

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. Poświadczenia mogą pochodzić z chronionego magazynu, zmiennych przekazanych przy starcie programu, odizolowanego środowiska programu (kontenera), automatycznego zadania budowania lub wdrażania (CI) albo połączenia zarządzanego przez dostawcę. W takich przypadkach pasujący plik lokalny może nie powstać.

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żda osoba administrująca potrzebuje indywidualnego konta 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. Dokumentacja integracji autoryzowanej przez użytkownika wskazuje konto i dozwolony sposób ponownego przyznania dostępu. Token innego konta ma uprawnienia tego konta i wymaga sprawdzenia wobec potrzebnych numerów kont Ads (customer IDs).
3. Tokeny odświeżania i poświadczenia usług należą do zatwierdzonego, chronionego magazynu danych dostępowych. Przebudowa serwera sama nie unieważnia tokena, lecz utrata poświadczenia może wymusić ponowną autoryzację.
4. Konta usług są rozwiązaniem do rozważenia dla zadań działających bez obecności osoby. 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. Procedura odtworzenia wymaga regularnej kontroli oraz ponownego sprawdzenia po zmianach kadrowych, uprawnień, poświadczeń lub systemów.

Poniższe zapytanie 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.