Google Ads API тепер вимагає Passkey для нових Refresh Token

Кожен, хто хоч раз автоматизував онбординг нового рекламодавця о 16:00 в п'ятницю, знає цінність єдиного OAuth-виклику, який просто працює. Тепер цей виклик матиме додатковий крок із passkey. Google вимагає автентифікації через passkey для будь-якого нового OAuth 2.0 refresh token, згенерованого через Google Ads API, і поетапне впровадження вже розпочалось.

Для платформних інженерів, які будують рішення поверх Google Ads, це саме той тип тихих змін API, що не ламає продакшн у перший день, але непомітно зламає вашу наступну міграцію клієнта через два місяці. Сфера застосування вузька. Але наслідки, якщо їх ігнорувати, — аж ніяк.

Ключові деталі

Вимога, як повідомляє ALM Corp, стала обов'язковою з 5 серпня 2026 року з поетапним розгортанням для акаунтів протягом наступних тижнів. Будь-який користувач, який проходить стандартний OAuth 2.0 flow для створення нового refresh token у Google Ads API, тепер повинен автентифікуватись через passkey замість пароля та коду двоетапної перевірки.

Механіка проста. Passkey використовують криптографічні ключі, а приватний ключ генерується та зберігається на пристрої користувача. Якщо у користувача не налаштовано passkey, його примусово змусять це зробити під час автентифікації. Немає passkey — немає refresh token.

Є дві деталі, важливіші за саму зміну.

По-перше, існуючі refresh token у безпеці. Токени, створені до 5 серпня, продовжують працювати. Це не подія масової анульації. Зміна стосується лише тих випадків, коли хтось запускає нову інтеграцію, підключає нового рекламодавця або ротує облікові дані.

По-друге, існує семиденна затримка довіри. Щойно створений passkey є функціональним, але вважається ненадійним протягом першого тижня. Google прямо рекомендує створювати passkey заздалегідь, щоб цей період завершився до того, як вам знадобиться автентифікація. Для агентств, які підключають клієнта менш ніж за тиждень, це проблема планування, замаскована під функцію безпеки.

Сфера дії поширюється не лише на прямі API-виклики. Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service та Looker Studio — всі вони підпадають під цю вимогу. Звичайні користувачі Scripts і Looker Studio також входять у цей перелік, а не лише бекенд-розробники. Будь-яка інтеграція, що з'єднує акаунт Google Ads з іншим застосунком, врешті-решт вимагатиме passkey.

Єдиний чіткий виняток: організації, що використовують service account. Оскільки service account не використовують стандартний flow автентифікації користувача, вони повністю виходять за рамки цієї вимоги. Ця одна фраза є найважливішим рядком в оголошенні для тих, хто проєктує нові інтеграції з нуля.

Чому це важливо для performance-маркетингу

Кожне агентство, з яким я працював протягом останнього десятиліття, має однаковий скелет у шафі: спільний акаунт Google, refresh token, виданий роки тому людиною, яка давно звільнилась, і cron-задача, яка тихо підтягує звіти щоранку. Цей токен досі працює. Добре. Але щойно ви підключаєте нового клієнта, запускаєте нову інтеграцію sub-MCC або мігруєте на новий стек звітності — ви потрапляєте в нові правила.

Операційний вплив поділяється на три напрями. SaaS-платформи, що продають інструменти управління Google Ads, повинні переробити свій UX онбордингу. Старий flow «натисніть тут, увійдіть через Google, готово» тепер включає крок налаштування passkey для користувачів, у яких його немає. Це не величезна робота, але це навантаження на підтримку. Очікуйте сплеск тікетів від клієнтів, які не знають, що таке passkey, і не розуміють, чому їхній Yubikey не працює так, як раніше працював менеджер паролів.

Агентства, які підключають нових рекламодавців, стикаються із семиденним вікном довіри як обмеженням планування. Якщо ваш стандартний SLA — «ми перенесемо ваші кампанії протягом 48 годин», то ця обіцянка тепер суперечить типовій позиції Google. Моя думка: агентствам слід додати пункт про налаштування passkey до передстартового чекліста, одразу після налаштування білінгу та доступу до пікселя відстеження.

Виробничі інциденти, які я спостерігав під час подібних міграцій автентифікації, мають передбачувану схему. Щось працює в staging, бо там використовуються довгоживучі токени. Потім продакшн-токен закінчується або ротується, flow повторної автентифікації натикається на нову вимогу, і звітність непомітно зупиняється. Ніхто не помічає, доки клієнт не запитує, куди поділись дані за минулий вівторок. Впровадження passkey особливо схильне до цього, бо режим відмови часто виглядає як «користувачу пропонується налаштувати passkey в безголовому контексті», що просто зависає.

Незручний висновок: якщо ваша платформа досі покладається на кінцевий OAuth користувача для безголових інтеграцій — це Google ввічливо каже вам переходити на service account.

Вплив на індустрію

Для ширшого стеку трафіку та performance-маркетингу це поштовх, а не удар, до більш захищеної позиції автентифікації. Passkey об'єктивно кращий захист, ніж пароль плюс TOTP. Приватний ключ ніколи не покидає пристрій, стійкість до фішингу вбудована, а поверхня атаки для credential stuffing зменшується. Жоден розсудливий фахівець не заперечує проти passkey як базового підходу.

Складність — у технічній реалізації. Постачальники ad-tech, менеджери ставок, інструменти автоматизації фідів, крос-канальні платформи звітності — всі вони будували онбординг, припускаючи, що людина за браузером може завершити OAuth-процес за один сеанс. Семиденне ненадійне вікно змушує перейти до двофазного онбордингу: спочатку налаштувати облікові дані, потім активувати інтеграцію. Команди, які сприймуть це як редизайн UX, а не просто галочку, опиняться у виграші.

Є також побічний ефект для BI-рівня. Якщо ваш пайплайн маркетингової аналітики використовує BigQuery Data Transfer Service для синхронізації даних Google Ads, і хтось відтворює цей трансфер під новим акаунтом — він наштовхнеться на вимогу passkey. Дашборди Looker Studio, якими керують фізичні особи, а не service account, — в тій самій ситуації. Очікуйте, що відділи фінансів та аналітики подаватимуть спантеличені тікети протягом наступного кварталу.

Стратегічний сигнал очевидний: Google стандартизує passkey по всій своїй розробницькій поверхні, і Ads API — великий перший доміно. Команди, які відкладали належний аудит управління секретами, міграцію на service account або консолідацію провайдера автентифікації, тепер мають привід діяти. Це здорово. Болісно, але здорово.

Варто зазначити для тих, хто жонглює мультиплатформними стеками: Marketing API від Meta має власну модель автентифікації із системними користувачами, яка обходить цей клас проблем, і є розумною точкою відліку щодо того, наскільки добре операційно тримаються патерни на кшталт service account.

На що звертати увагу

Три сигнали покажуть вам, наскільки складним буде наступний квартал.

Стежте за тим, як SaaS-постачальники тихо оновлюють свою документацію з онбордингу, додаючи інструкції щодо passkey. Постачальники, що надають чіткі інструкції протягом першого місяця поетапного впровадження, — це ті, у кого є інженерна дисципліна. Ті, хто в листопаді досі показує скриншоти «увійдіть за допомогою пароля Google», — це ті, кому варто ставити серйозні запитання.

Стежте за власним календарем ротації токенів. Якщо у вас є refresh token на плановій ротації, перевірте, чи ця ротація ініціює видачу нового токена, чи повторно використовує існуючий. Політики ротації, написані до 5 серпня, можуть тепер ненавмисно втягнути вас у flow passkey у найгірший момент.

Стежте за хвилею міграції на service account. Google фактично підвищив операційну вартість кінцевого OAuth порівняно з автентифікацією через service account для безголових навантажень. Будь-яка команда, що досі використовує людський акаунт для запуску бекенд-завдань Ads API, повинна мати пункт «мігрувати на service account» у дорожній карті до кінця кварталу. Не тому, що небо падає, а тому що альтернатива — пояснювати вашому CTO, чому звітність зламалась через вікно довіри passkey під час демо для клієнта.

Ключові висновки

• Лише нові токени: Існуючі OAuth refresh token, створені до 5 серпня 2026 року, продовжують працювати. Паніка — не відповідь, відповідь — планування.
• Семиденна затримка довіри — це проблема планування: Налаштовуйте passkey принаймні за тиждень до того, як вам потрібно підключити нового рекламодавця або інтеграцію.
• Service account — це запасний вихід: Безголові навантаження слід мігрувати з кінцевого OAuth користувача. Google дав вам причину; скористайтесь нею.
• UX онбордингу потребує переробки: SaaS-платформи, що керують акаунтами Google Ads від імені клієнтів, повинні додати налаштування passkey до свого flow та документації підтримки.
• Сфера ширша за API: Google Ads Editor, Scripts, BigQuery Data Transfer та інтеграції Looker Studio — всі вони підпадають під ту саму вимогу. Проведіть аудит кожної поверхні, а не лише очевидної.