Google Ads API richiederà le passkey per i nuovi token

La novità impatta il flusso OAuth 2.0, mentre i token esistenti restano validi e i servizi server-to-server non subiscono variazioni

Domani, 5 agosto 2026, scatterà un cambiamento che a prima vista sembra un aggiornamento di routine nella documentazione per sviluppatori: l’API di Google Ads richiederà l’autenticazione tramite passkey per generare nuovi token di aggiornamento OAuth 2.0. Chi opera nell’ad-tech sa che i dettagli tecnici nascondono spesso meccanismi di controllo ben più profondi, e questa mossa non fa eccezione. Dietro la patina della sicurezza si intravede un tassello nella progressiva chiusura dell’ecosistema Google, con effetti a catena su sviluppatori, inserzionisti e flussi di automazione che tengono in piedi il programmatic advertising.

La modifica, annunciata la scorsa settimana dal team Google Ads Developers, ha un perimetro preciso: i token di aggiornamento OAuth già esistenti continueranno a funzionare senza interruzioni, e i flussi basati su account di servizio — quelli che alimentano pipeline server-to-server senza interazione umana — restano intatti. Il colpo si concentra sui nuovi token: chi vorrà generare credenziali fresche attraverso il flusso di autenticazione utente dovrà passare dal riconoscimento biometrico o dal PIN del dispositivo. Un gesto che sposta la barriera dal codice all’identità fisica di chi quel codice lo esegue.

Questa mossa non è isolata. Si inserisce in una traiettoria che ha visto Google rendere le passkey l’opzione predefinita per gli account personali già nell’ottobre 2023, per poi estendere la logica ai prodotti pubblicitari con crescente determinazione: lo scorso 21 aprile è scattata l’autenticazione multifattoriale obbligatoria per l’API Google Ads, e a metà luglio le passkey sono diventate requisito per le azioni sensibili nell’interfaccia utente di Google Ads. La sequenza disegna un arco che va dall’utente consumer all’advertiser enterprise, restringendo progressivamente gli spazi di manovra dell’automazione senza supervisione.

Il nuovo cancello

Per chi sviluppa integrazioni con l’API Google Ads, il flusso OAuth 2.0 è l’infrastruttura su cui poggia l’intero edificio dell’automazione: generare un refresh token significa abilitare uno script, un’applicazione di terze parti o un middleware a gestire campagne, estrarre report e modificare offerte senza che un operatore umano debba autenticarsi ogni volta. L’introduzione della passkey spezza questo automatismo nel momento più delicato: la creazione del token stesso. Non è più sufficiente che il codice giri su un server autorizzato; serve che una persona fisica, dotata del dispositivo che custodisce la passkey, compia un gesto deliberato — impronta digitale, scansione del volto, PIN — per sbloccare l’accesso.

Il contrasto è stridente. Google presenta la novità come un aggiornamento di sicurezza, ed è innegabile che le passkey offrano una protezione superiore contro phishing e furto di credenziali rispetto alle password tradizionali. Tuttavia, per chi gestisce decine di account pubblicitari attraverso strumenti di terze parti — agenzie, piattaforme di marketing automation, DSP che si integrano con l’inventory di Google Ads — ogni passkey diventa un collo di bottiglia operativo. Non è solo una questione di attrito: è una ridefinizione implicita di chi può accedere ai dati e in quali condizioni. Il muro si alza proprio nel punto in cui l’automazione incontra l’identità umana.

Chi vince e chi perde

Se leggiamo la mossa attraverso la lente di chi guadagna e chi perde, il bilancio si fa più chiaro. Google guadagna un controllo granulare sull’accesso programmatico alle proprie API pubblicitarie, rafforzando la posizione del proprio ecosistema come ambiente regolato dove ogni interazione è tracciabile fino a un’identità verificata. In un mercato dove la trasparenza della supply chain è sotto scrutinio costante — si pensi alle pressioni su quality e viewability, alle indagini sull’arbitraggio, ai timori di traffico non valido — poter dire che ogni token OAuth è legato a una passkey biometrica è un argomento potente da spendere con regolatori e investitori pubblicitari.

Gli sviluppatori perdono agilità. Chi costruisce strumenti per l’automazione multi-account — script di ottimizzazione, piattaforme di bidding algoritmico, connettori per data warehouse — deve ora progettare flussi che prevedano l’interruzione umana come passaggio obbligato. Non basta più il provisioning automatico delle credenziali; serve un momento in cui qualcuno prende in mano il telefono e autorizza. Per le agenzie che gestiscono centinaia di account cliente, il costo operativo di questa frizione si moltiplica. C’è un’ironia sottile: la sicurezza viene brandizzata come protezione dell’utente finale, ma chi paga il prezzo più alto sono proprio gli operatori tecnici che costruiscono l’infrastruttura pubblicitaria su cui Google stessa si appoggia.

Il percorso che ha portato fin qui è istruttivo. Microsoft ha iniziato a richiedere l’MFA per le API pubblicitarie fin dal giugno 2022, tracciando una strada che Google ha seguito con un approccio più graduale ma anche più invasivo: prima l’MFA obbligatoria ad aprile 2026, poi le passkey per le azioni sensibili nell’interfaccia utente a luglio, ora il requisito per l’API stessa. Ogni passo stringe il perimetro, e il pattern suggerisce che la direzione è a senso unico. Resta una domanda: quando la sicurezza smette di essere uno strumento di protezione e diventa un ostacolo all’innovazione? O, più precisamente, quando la protezione dell’ecosistema coincide con la protezione da chi vorrebbe operare al suo interno con troppa libertà?

L’automazione in bilico

Uno degli aspetti meno discussi dell’annuncio è il ritardo di sicurezza di sette giorni: una nuova passkey potrebbe non diventare immediatamente operativa per l’API Google Ads, con una finestra di attesa prima che il sistema la consideri attendibile. Sette giorni nel programmatic sono un’eternità. Una campagna che deve partire in fretta, un’integrazione urgente per un cliente, una migrazione da un fornitore all’altro: in tutti questi scenari, il ritardo imposto dalla fiducia della passkey può inceppare flussi che oggi funzionano in tempo reale. Non è un bug, è una feature dichiarata: la sicurezza ha un costo in termini di velocità, e quel costo ricade su chi opera ai bordi dell’ecosistema Google.

E gli altri walled garden? Amazon Advertising, Meta, TikTok: ciascuno sta costruendo la propria cittadella con regole di accesso sempre più stringenti, e la mossa di Google rischia di fare da apripista. Se il mercato accetta che per generare un token OAuth serva una passkey, quanto ci vorrà prima che lo stesso requisito venga esteso alle API di reporting, alle integrazioni con le clean room, ai connettori per i retail media network? La partita è appena iniziata, e la domanda non è se altri seguiranno, ma quando e con quali varianti.

La sicurezza diventa un’arma a doppio taglio: mentre Google alza i muri, chi opera nell’ad-tech deve chiedersi se il prezzo della flessibilità sia diventato troppo alto. Per ora, i token esistenti continuano a funzionare, e questo concede una finestra di respiro. Ma ogni nuovo flusso, ogni nuova integrazione, ogni sviluppatore che si affaccia per la prima volta all’API Google Ads troverà un cancello che prima non c’era. E dietro quel cancello, la domanda resta aperta: protezione o controllo?