Google Ads API kräver passkeys från augusti 2026

Google inför krav på passkeys i inloggningsflödet i Google Ads API som utfärdar nya autentiseringsuppgifter, och förändringen börjar rullas ut den 5 augusti 2026. Det användarautentiseringsflödet som genererar nya OAuth 2.0-refresh-tokens måste klara en passkey-utmaning, och inloggning med enbart lösenord samt äldre tvåfaktorsmetoder, som SMS-koder och tidsbaserade engångslösenord, accepteras inte längre för det steget. För företag och byråer som hanterar Google Ads i stor skala genom automatisering är detta en absolut säkerhetsdeadline, inte en valfri uppgradering.

Vad har hänt

Den 27 juli 2026 meddelade Google Ads Developer Blog att “Google Ads API kommer att börja kräva passkeys för användare av Google Ads API.” Utrullningen är planerad att inledas den 5 augusti och nå alla användare under de följande veckorna.

Kravet gäller det användarautentiseringsflöde som skapar nya OAuth 2.0-refresh-tokens. Befintliga refresh-tokens påverkas inte: de fortsätter att fungera, och integrationer uppmanas inte att autentisera på nytt när de växlar in dem mot access-tokens. Det som förändras är själva momentet att godkänna en ny token. Nya användare möts av en passkey-utmaning vid inloggning, och om ingen passkey finns uppmanas de att skapa en. Google flaggar också för en säkerhetsfördröjning på upp till sju dagar innan en nyskapad passkey blir betrodd och användbar, vilket är anledningen till att företaget rekommenderar att man skapar en i god tid i stället för i det ögonblick en token måste utfärdas.

Omfattningen sträcker sig längre än kod som skrivs direkt mot API:et. Google namngav Google Ads Editor, Google Ads scripts, BigQuery Data Transfer Service och Data Studio-kopplingar som exempel på verktyg som också kommer att börja kräva passkey-baserad autentisering.

Varför det spelar roll

Lösenord och engångskoder via SMS eller appar är just de faktorer som nätfiske och kontokapningar är byggda för att fånga upp. Passkeys är motståndskraftiga mot nätfiske: de är knutna till den äkta webbplatsen och kan varken fiskas upp eller återanvändas på samma sätt som ett lösenord eller en engångskod, vilket gör att förändringen stänger en väl beprövad väg in i annonskonton som rymmer budgetar och kunddata. Avvägningen ligger i det operativa: alla team som har automatiserat sin tokengenerering utifrån antagandet att ett lösenord plus en engångskod räcker har nu ett steg som ett skript inte tyst kan slutföra.

Vad detta betyder för företag med flera platser

För ett centralt marknadsförings- eller martech-team som driver Google Ads över hundratals eller tusentals platser ligger risken i ett tyst avbrott i automatiseringen snarare än en utelåst inloggning. Massuppladdningar via Google Ads Editor, schemalagda skript och BigQuery-dataöverföringar bygger alla på det tokenflöde som förändras, och en token som inte kan förnyas i augusti stoppar det flöde den försörjer.

Arbetet som ska göras före deadline handlar om styrning, inte om klick. Inventera varje integration och koppling som kör användarautentiseringsflödet mot Google Ads API, eftersom det är det flödet som förändras. Tjänstekontoåtkomst använder egna autentiseringsuppgifter och omfattas inte av kravet. Bekräfta vilka användaridentiteter som utfärdar nya refresh-tokens, och se till att en betrodd passkey redan är registrerad på var och en av dessa identiteter, med marginal för den sjudagars förtroendefördröjningen. Bestäm vem som innehar passkeys för delade eller teamhanterade konton, och dokumentera beslutet, så att en enskild medarbetares enhet inte blir anledningen till att en hel nationell kampanjportfölj inte kan autentiseras på nytt. Att skärpa åtkomsten till de plattformar som bär upp er närvaro och annonsdata är samma disciplin som ligger bakom PinMeTos ISO 27001-certifiering och hållning kring datalagring inom EU: kontrollera vem och vad som kan komma åt kontona, och kunna visa det.

“Google Ads API kommer att börja kräva passkeys för användare av Google Ads API.”

Google Ads Developer Blog

Slutsatsen

Befintliga automatiseringar fortsätter att köras på sina nuvarande refresh-tokens, och rutinmässiga förnyelser av access-tokens påverkas inte, så inget går sönder den 5 augusti i sig. Exponeringen uppstår första gången varje integration måste skapa en ny OAuth-refresh-token efter utrullningen, och det är då en saknad passkey blir ett stoppat arbetsflöde. Företag som hanterar Google Ads och sina platsdata via PinMeTos API-svit och samordnar betald lokal aktivitet via lokala annonskampanjer bör registrera passkeys och utse ansvariga redan nu, innan utrullningen inleds den 5 augusti och når deras konton under veckorna därefter, och bör räkna med den sjudagars förtroendefördröjningen för passkeys när de gör det.