Google OAuth: giv appen adgang uden at dele adgangskoder

Google OAuth lader en bruger give en app afgrænset adgang til eksempelvis Drive, Gmail eller Kalender. Brugeren beholder sin Google-adgangskode, kan se hvilke tilladelser appen beder om og kan trække adgangen tilbage. Sikkerheden afhænger stadig af, at appen vælger de rigtige scopes og beskytter callback, klientoplysninger og tokens.

OAuth-adgang er ikke det samme som login

“Log ind med Google” handler om at identificere brugeren. OAuth-adgang til en Google API handler om, hvad appen må gøre på brugerens vegne. De to flows kan optræde sammen, men et vellykket login giver ikke automatisk adgang til mail, filer eller kalender.

Brugerens Google-data

Brug brugerautorisation, når appen skal handle på vegne af den konkrete bruger i Drive, Gmail eller Kalender.

Projektets egne cloudressourcer

En service account kan passe til server-til-server-kald mod projektbaserede Google Cloud-ressourcer. Den erstatter ikke automatisk en brugers samtykke til personlige Workspace-data.

Vælg flow efter hvem der ejer data, hvem handlingen udføres for, og om appen skal kunne arbejde, mens brugeren ikke er til stede.

Beskriv handlingen før I vælger scope

Et scope er den tilladelse, samtykkeskærmen beder brugeren om. Start ikke med en bred tilladelse “for en sikkerheds skyld”. Skriv den konkrete funktion ned, find det mindst omfattende aktuelle scope i Googles dokumentation, og bed først om det, når brugeren vælger funktionen.

Funktion i appen	Afgrænsning, der skal undersøges	Spørgsmål før samtykke
Gem en fil i Drive	Filer appen selv opretter eller brugeren åbner med appen frem for hele Drive	Skal appen se eksisterende filer, eller kun arbejde med udvalgte filer?
Send en mail	Sendetilladelse frem for læse- eller ændringsadgang til postkassen	Skal appen kun sende, eller også læse, søge og ændre mails?
Opret en kalenderaftale	Adgang til relevante kalenderhændelser frem for alle kalenderindstillinger	Skal appen oprette, læse, ændre eller slette – og i hvilke kalendere?

Brug Googles aktuelle scopeoversigt i stedet for at kopiere et scope fra et gammelt kodeeksempel. Omfang og klassifikation påvirker både brugerens risiko og hvilke krav appen kan møde før offentlig brug.

Vælg målgruppe og miljø med vilje

I Google Auth Platform vælger I, hvem der kan godkende appen. En intern målgruppe kan bruges af projekter i en Google Cloud-organisation og begrænser flowet til organisationens brugere. En ekstern målgruppe er til brugere med Google-konti uden for organisationen. Teststatus er til navngivne testbrugere – ikke som skjult produktionsløsning.

Udvikling: Brug localhost og testkonti uden produktionsdata.
Test eller staging: Brug en særskilt OAuth-klient og helst et særskilt cloudprojekt, når data, brugere eller verificering skal holdes adskilt.
Produktion: Registrér kun de rigtige produktionsdomæner og callbacks. Googles produktionsvejledning fraråder test-redirects og interne udvikler-origins i produktionsklienten.

En Google Workspace-administrator kan begrænse tredjepartsapps eller scopes. Hvis løsningen er til en kundes organisation, skal det derfor være dokumenteret, hvem der ejer cloudprojektet, og hvem der kan godkende klient-id'et i Workspace.

Konfigurér samtykkeskærmen som en rigtig driftsdel

Brugeren skal kunne genkende appen og forstå, hvorfor den beder om adgang. Udfyld appnavn, supportkontakt, autoriserede domæner og de relevante offentlige sider med korrekte oplysninger. Beskriv funktionen før Google-dialogen åbnes, og forklar hvad der sker, hvis brugeren siger nej.

Vis samtykke i forbindelse med den funktion, der kræver adgang – eksempelvis “Forbind Google Kalender”.
Bed om scopes gradvist, når funktionen bruges, i stedet for at samle alle fremtidige ønsker ved første login.
Håndtér at brugeren kun giver nogle tilladelser. Slå de berørte funktioner fra uden at gøre resten af appen ubrugelig.
Vis hvilken Google-konto der er forbundet, hvilke funktioner forbindelsen bruges til, og hvordan den afbrydes.

Beskyt authorization code-flowet på serveren

En webapp med backend bør bruge Googles webserver-flow eller den relevante officielle klientbibliotek. Klientens secret og udvekslingen af authorization code hører til på serveren, som kan opbevare fortrolige oplysninger – ikke i browserkoden.

1. Brugeren vælger en Google-funktion. Backend kontrollerer den lokale session og den funktion, der kræver adgang.
2. Appen opretter state. Generér en unik, ikke-gættelig værdi, bind den til brugerens session, og send den med til Google.
3. Google viser konto og samtykke. Brugeren godkender eller afviser de viste scopes.
4. Callback kontrolleres. Verificér state og håndtér afslag eller fejl, før authorization code bruges.
5. Koden veksles på serveren. Backend bruger den korrekte klient og præcis samme redirect URI til at hente tokens.
6. De tildelte scopes gemmes. Stol ikke på, at alle ønskede scopes blev givet; knyt de faktiske tilladelser til forbindelsen.

Redirect URI skal matche præcist. Protokol, domæne, sti og afsluttende skråstreg er en del af værdien. Et wildcard eller en dynamisk callback baseret på brugerinput hører ikke hjemme i flowet. Brug HTTPS i drift; Google tillader localhost-adresser til lokal test.

Behandl refresh token som en varig nøgle

Et access token bruges til API-kald og har begrænset levetid. Hvis appen skal arbejde, mens brugeren ikke er i browseren, kan den anmode om offline-adgang og modtage et refresh token, som kan skaffe nye access tokens. Det gør refresh tokenet mere følsomt end en almindelig session i browseren.

Opbevar server-side: Krypter brugerens tokens i en ikke-offentlig database eller anden passende sikker lagring.
Adskil app-secret og brugertokens: Klient-secret hører i secret storage; tokens hører til den konkrete bruger, kunde og OAuth-klient.
Send ikke tokens i URL'er: Brug Authorization-header til API-kald, så tokenet ikke ender i almindelige URL-logs og browserhistorik.
Log ikke værdien: Log forbindelses-id, scope, resultat og fejlkode – ikke access token, refresh token eller authorization code.
Håndtér ugyldighed: Brugeren eller Google kan tilbagekalde eller ugyldiggøre et token. Appen skal stoppe baggrundsjob roligt og bede om ny forbindelse, når det er relevant.

Google kan kun returnere refresh token under bestemte samtykkesituationer. Byg ikke flowet på, at et nyt refresh token altid følger med enhver callback; bevar et gyldigt eksisterende token sikkert, og test genforbindelse uden datatab.

Gør afbrydelse og tilbagekaldelse til en funktion

Brugeren skal kunne afbryde Google-forbindelsen i appen. Stop planlagte jobs, tilbagekald adgangen hos Google, og slet lokale tokens, når de ikke længere er nødvendige. Beslut særskilt hvad der skal ske med data, som appen allerede har oprettet eller kopieret; token-tilbagekaldelse sletter ikke automatisk jeres egne data.

Dokumentér også offboarding: Hvad sker der, når en medarbejder forlader virksomheden, en Google-konto lukkes, en Workspace-administrator blokerer appen, eller ejeren af en delt kalender ændres? Fejlen skal føre til en synlig driftsstatus – ikke endeløse retries eller skjulte mangler i synkroniseringen.

Forbered verifikation før kunderne venter

En ekstern app, der beder om bestemte brugerdata, kan skulle gennem Googles verificering af branding, domæner og scopes. Restricted scopes kan udløse yderligere krav. Det præcise forløb afhænger af appens målgruppe og de aktuelle scopes, så kontrollér Googles produktionsvejledning, før integrationen bliver en kritisk del af en lanceringsdato.

Fjern scopes, som koden ikke bruger, og dokumentér hvor hvert resterende scope bruges.
Sørg for at appens offentlige startside, privatlivspolitik og domæner stemmer med samtykkeskærmen og det faktiske dataflow.
Gør testflowet forståeligt for en reviewer uden intern mundtlig viden.
Indfør ikke test-URL'er og lokale origins i produktionsklienten for at løse en hurtig fejl.

Test både samtykke, drift og tab af adgang

Rigtig og forkert state, afvist samtykke og callback med fejl.
Forkert redirect URI, forkert OAuth-klient og forsøg på at blande test og produktion.
Kun nogle tildelte scopes samt en bruger, der senere fjerner en tilladelse.
Udløbet access token med gyldigt refresh token og ugyldigt eller tilbagekaldt refresh token.
Flere Google-konti i samme browser og tydelig visning af den faktisk forbundne konto.
Workspace-politik, der afviser klienten eller et scope, uden at resten af appen går ned.
Afbryd forbindelse, stop baggrundsjob, slet tokens og tilslut igen.
Logs, fejlsporing og supportvisning uden secrets, authorization codes eller tokens.

Typiske fejl

Alle scopes anmodes ved login: Brugeren møder en bred adgangsanmodning, før funktionen giver mening.
Client secret ligger i frontend: En værdi, som alle browsere kan hente, kan ikke behandles som hemmelig.
State mangler eller genbruges: Callbacken bindes ikke sikkert til det flow og den session, der startede forbindelsen.
Test og produktion deler klient: Redirects, brugere, tokens og ændringer i samtykkeskærmen bliver svære at styre.
Refresh token overskrives med tom værdi: En senere callback ødelægger en fungerende baggrundsintegration.
Et afslag bliver en systemfejl: Brugeren kan ikke bruge resten af appen uden den valgfrie Google-funktion.
Ingen ejer verificering og Workspace-godkendelse: En teknisk færdig integration stopper ved kundens administrator eller Googles produktionskrav.
Afbryd skjuler kun knappen: Tokens, jobs og kopierede data lever videre uden synlig forbindelse.

Tjekliste før medarbejdere eller kunder forbinder Google

☐ Det er afklaret, om behovet er Google-login, brugerautorisation eller en service account.
☐ Hver Google-funktion er knyttet til det mindst omfattende aktuelle scope.
☐ Målgruppe, cloudprojekt, dataejer og ansvarlig Workspace-administrator er dokumenteret.
☐ Udvikling, test og produktion har adskilte klienter, callbacks og secrets.
☐ Samtykkeskærmen forklarer korrekt appnavn, formål, kontakt og relevante offentlige sider.
☐ Redirect URI matcher præcist, og produktionscallback bruger HTTPS.
☐ En unik, ikke-gættelig state bindes til sessionen og kontrolleres før code exchange.
☐ Client secret, authorization code, access token og refresh token holdes ude af frontend, URL'er og logs.
☐ Faktisk tildelte scopes gemmes, og appen fungerer forståeligt ved delvist eller afvist samtykke.
☐ Tokenfornyelse, ugyldigt token, administratorblokering og genforbindelse er afprøvet.
☐ Brugeren kan afbryde forbindelsen, tilbagekalde adgang og få lokale tokens slettet.
☐ Produktions- og verificeringskrav er afklaret ud fra målgruppe og de konkrete scopes.
☐ Driftsovervågning opdager stoppede baggrundsjob uden at gemme følsomme tokens.

Relaterede guides

API-nøgler, secrets og sikker rotation API-sikkerhed og sikre integrationer Logning og overvågning af baggrundsjob Microsoft SSO med Entra ID Se hele guidebiblioteket

Officielle kilder

Googles konsolnavne, scopes, politikker og verifikationskrav kan ændre sig. Brug de aktuelle primærkilder nedenfor til den konkrete app, og kontrollér igen før ændringer i målgruppe, scopes eller produktionsopsætning.