Kort om ændringen
Fra august kræver Google Ads API, at nye OAuth 2.0 fornyelsestokens (refresh tokens) oprettes med passkeys som en del af godkendelsen. Det betyder ikke, at eksisterende tokens fjernes, men nye autorisationer uden passkeys afvises — hvilket kan stoppe nye integrationer eller genautoriseringer.
Et eksempel kan være en lille webshop, der lader et marketingbureau oprette adgang via OAuth. Hvis bureauet forsøger at generere et nyt refresh token efter august uden at bruge passkeys, vil forbindelsen blive blokeret, indtil passkeys er implementeret.
Praktisk takeaway: Kortlæg hvem der opretter refresh tokens i din forretning og sørg for, at både interne og eksterne parter kan bruge passkeys inden deadline.
Hvorfor implementeringen betyder noget
Passkeys (baseret på WebAuthn/FIDO2) fjerner svage adgangskoder og reducerer risikoen ved token-tyveri. For udviklere og SaaS-platforme ændrer det den måde, brugere autoriserer applikationer på — godkendelsen bliver bundet til en fysisk eller platformbaseret authenticator.
Vi ser ofte virksomheder undervurdere operational overhead: systemer til at oprette og genoprette adgang, dokumentation til kunder og opdaterede onboarding-flow. Mange virksomheder fejler her ved kun at informere teknikerne uden at opdatere kunde- eller partner-vejledninger.
Praktisk takeaway: Sikkerheden øges, men arbejdsgangen ændres — planlæg kommunikation, support og dokumentation, så dine kunder ikke mister adgang.
Sådan forbereder du dit team
Start med et konkret teknisk og organisatorisk tjek. Følg nedenstående prioriterede trin for at minimere driftsstop.
- Inventar: Kortlæg alle apps, brugere og systemer, der genererer refresh tokens for Google Ads API.
- Testmiljø: Tilføj passkey-flow i staging og test end-to-end autorisation mod Google Ads API inden august.
- Brugerflow: Implementer WebAuthn-registrering i din OAuth-godkendelsesproces, inkl. mulighed for platform- og hardware-nøgler.
- Nødplan: Opret en sikker proces til recovery og nøgleadministration for mistede passkeys (fx ekstra hardware-nøgle i sikker opbevaring eller administrativ fallback med stram audit).
- Support og dokumentation: Opdater onboarding, prints og trin-for-trin vejledninger til kunder og interne teams; afhold kort træning for medarbejdere og bureaupartnere.
Et praktisk eksempel: Et lille bureau med tre ansatte kan have én admin-maskine med en hardware sikkerhedsnøgle i et brandsikkert skab. De implementerer WebAuthn i deres klientportal, så kunder selv kan registrere passkeys ved godkendelse. Dette minimerer support-henvendelser og sikrer hurtig reautorisation.
Praktisk takeaway: Gennemfør inventar og testtidligt, og hav en recovery-proces til passkeys.
Berørte værktøjer og funktioner
Følgende roller og værktøjer påvirkes direkte:
- Udviklere og API-klienter, der håndterer OAuth-flow og refresh tokens.
- Bureauer og konsulenter, der ofte opretter access for kunder via en enkelt admin-konto.
- SaaS-platforme, der tilbyder “tilslut din Google Ads”-funktionalitet til kunder.
- CI/CD-systemer og automatiserede scripts, der bruger interaktiv OAuth (disse kræver redesign hvis de skal bruge menneskelige passkeys).
Vi ser ofte, at SaaS-løsninger forsøger at bevare headless flows. Vær opmærksom: hvis din løsning kræver interaktive passkey-registreringer, må du indbygge en proces hvor en ansvarlig person kortvarigt gennemfører registreringen og dokumenterer det sikkert.
Praktisk takeaway: Kortlæg både menneskelige og automatiserede flows, og redesign automatiseringer der ikke kan bruge service-konti med passende sikkerhedsmekanismer.
Konkrete integrations- og supportråd
Nogle konkrete skridt, som tekniske teams kan handle på nu:
- Implementer WebAuthn-biblioteker der understøtter både platform- og roaming-authenticators (mobil, browser, hardware key).
- Opdater OAuth-konsent og redirect-URI’er i Google Cloud Console samt dokumentér hvilke Google-konti der skal have passkeys sat op.
- Sørg for logging og audit for nye token-udstedelser — registrer hvem der opretter passkeys og hvornår.
- Kommunikér til kunder i god tid: send vejledninger, estimér teknisk tid (fx 30 minutter pr. kunde for opsætning) og tilbyd assistance.
Et konkret scenario: En SaaS-platform tilbyder automatisk kampagnestyring for 200 kunder. Platformens team planlægger en weekendmigrering, hvor et mindre team manuelt gennemfører passkey-registrering for virksomhedskonti og verificerer tokens i staging først. De sørger for et fallback-dokument med kontakt til kunden i tilfælde af problemer.
Praktisk takeaway: Kombiner teknisk implementering med en kommunikationsplan, så kunder oplever minimal forstyrrelse.
Konklusion og næste skridt
Passkeys øger sikkerheden i Google Ads API, men kræver planlægning: identificer alle token-flow, opdatér OAuth-godkendelsen med WebAuthn, test i staging og træn supportteams. Mange virksomheder fejler ved kun at opdatere kode uden at hjælpe brugerne med registrering og recovery.
Kilde: Artiklen er baseret på og omskrevet fra den oprindelige artikel.
Praktisk konklusion: Start straks med inventar og tests, prioriter kundekommunikation, og hav en sikker recovery-proces for passkeys klar.
