З 5 серпня 2026 року Google робить використання passkeys обов'язковим для генерації нових OAuth 2.0 refresh-токенів у Google Ads API. Компанія прибирає традиційні паролі та SMS-двофакторку, щоб ускладнити викрадення доступу до бюджетів. Для арбітражних команд, агенцій та розробників SaaS-сервісів це означає нову проблему з доступами: свіжі ключі безпеки можуть блокувати логін на 7 днів.
Що саме змінюється в алгоритмі авторизації
Перехід на обов'язкові passkeys стосується лише user authentication workflow. Апдейт розкочуватимуть поступово протягом кількох тижнів після старту.
Головні факти про оновлення:
Старі методи відпадають. Паролі, SMS-коди та TOTP-додатки більше не підходять для підтвердження доступу під час генерації нових refresh-токенів.
Поточні токени працюють. Вже існуючі OAuth-токени не підпадають під нові правила. Переавторизація для працюючих сервісів не потрібна.
Service accounts без змін. Якщо ваші додатки використовують Service accounts для автоматизації (наприклад, вивантаження статки по API), нічого міняти не треба. Google рекомендує саме цей метод для бекенд-інтеграцій.
Чому Google це робить
У 2026 році крадіжка рекламних акаунтів стала масовою. Кабінети агенцій зламували через фішинг і перехоплення сесій, щоб отримати доступ до клієнтських бюджетів.
Google ще в середині липня ввів обов'язкові passkeys для критичних дій у веб-інтерфейсі (розшарювання доступу, зміна платіжок). Тепер вимогу перенесли на рівень API, через який зовнішні платформи керують кампаніями, бюджетами та структурою заливу.
Passkey жорстко прив'язаний до фізичного пристрою через Face ID, Touch ID або PIN-код. Його не можна перехопити через фейкову сторінку логіну.
Пастка на 7 днів: чим це загрожує медіабаєрам
Проблема для агенцій та команд полягає в механіці трасту нових ключів. Новостворений passkey отримує статус довіреного не одразу. Залежно від трасту акаунта, Google може накласти 7-денну безпекову затримку.
Якщо клієнт або баєр спробує створити passkey у день прив'язки акаунта до трекера чи спай-тула, інтеграція зависне на тиждень. Система не надішле повідомлень про блокування — процес логіну просто не завершиться до кінця холду. Ключі треба генерувати заздалегідь на тих пристроях, з яких іде реальна робота.
Які ще інструменти потрапили під роздачу
Оновлення зачепить не лише самописні тули, а й усю аналітику на базі Google Ads API. Правило обов'язкового passkey також діятиме для:
➡️ Google Ads Editor ➡️ Google Ads Scripts ➡️ BigQuery Data Transfer Service ➡️ Looker Studio
Якщо баєр спробує підтягнути дані в Looker Studio або запустити скрипт через особистий токен без налаштованого passkey, система видасть помилку і змусить створювати ключ. Це знову ж таки загрожує холдом на 7 днів.
Як адаптувати арбітражну інфраструктуру
Технічним командам доведеться переглянути поточні інтеграції, щоб не зловити стоп під час масштабування.
Проведіть ревізію токенів. Знайдіть усі скрипти та тули, які працюють через особисті OAuth-токени співробітників (User authentication workflow).
Перейдіть на Service accounts. Фонові процеси (оновлення аудиторій, автоставки, бекапи в BigQuery) краще перевести на сервісні акаунти. Це відв'язує інфраструктуру від конкретного баєра. Якщо людина звільняється, інтеграція не ламається.
Генеруйте ключі наперед. Баєрам та фармерам треба зайти в налаштування безпеки Google-акаунтів і створити passkeys вже зараз. Через можливу затримку ключі мають відлежатися і отримати траст до того, як знадобляться для роботи з API.
Висновки
Вимога генерувати passkeys для нових OAuth-токенів вдарить по швидкості онбордингу нових клієнтів та інтеграцій. Працюючі інструменти не відваляться, але для нових підключень після 5 серпня агенціям доведеться закладати тижневий холд на апрув ключа. Оптимальний варіант для автоматизації заливу — перевести бекенд на Service accounts, де не потрібна ручна авторизація через пристрої 😬