Hvad er OAuth? „Log ind med Google“ og delegeret adgang forklaret

OAuth er en åben standard, der lader en bruger give én app begrænset adgang til sin konto hos en anden tjeneste – uden at overdrage sin adgangskode. Når du klikker „Forbind Google Kalender“ og ser en skærm, der spørger „Må denne app se dine begivenheder?“, er det OAuth. Appen får et token til præcis det, du godkendte, som du til enhver tid kan tilbagekalde. Den samme mekanisme, med et ekstra lag kaldet OpenID Connect, driver „Log ind med Google“ og lignende knapper.

Hvorfor OAuth betyder noget, når du bygger med AI

OAuth dukker op i to almindelige situationer, når du bygger en app:

1. Social login. Du vil have, at brugerne „logger ind med Google“ (eller Apple, Microsoft, GitHub) i stedet for at oprette endnu en adgangskode. Se sådan tilføjer du login til din app.
2. Forbindelse til brugeres konti hos andre tjenester. Din app skal læse en brugers kalender, poste på vedkommendes sociale konto, hente filer fra deres cloud-drev eller synkronisere deres regnskabsdata.

I begge tilfælde kan din AI-builder skrive koden, men nogle trin kan kun du gøre: oprette en udviklerapp hos udbyderen, få et client ID og en client secret, registrere callback-URL'er og for nogle tilladelser bestå udbyderens gennemgang. At forstå, hvordan OAuth virker, gør de trin – og de fejl de giver – meget mindre mystiske. For det større billede af login, se hvad autentificering er.

En hverdagsanalogi

Tænk på et hotel-nøglekort. Ved check-in bekræfter receptionen, hvem du er, og giver dig et kort, der åbner dit værelse og fitnesscentret – ikke de andre værelser, ikke personaleområderne – og holder op med at virke ved check-out. Kortet indeholder ikke dit pas. Hvis du mister det, annullerer receptionen det og udsteder et nyt.

• Receptionen er autorisationsserveren (Googles login-side).
• Din ID-kontrol er, at du logger ind hos Google.
• Nøglekortet er adgangstokenet.
• „Værelse og fitness kun“ er de scopes, du godkendte.
• Check-out er, at tokenet udløber, eller at du tilbagekalder adgangen.

Appen, du bruger, ser aldrig din Google-adgangskode, kun nøglekortet.

Sådan virker OAuth, trin for trin

Det mest almindelige flow til webapps er authorization code flow. Her er hvad der sker, når en bruger forbinder sin Google-kalender til en planlægningsapp:

1. Klik. Brugeren klikker „Forbind Google Kalender“.
2. Omdirigering til udbyderen. Appen sender browseren til Google med sit client ID, de scopes den vil have (læse kalenderbegivenheder) og redirect URI'en, hvor Google skal sende brugeren tilbage til.
3. Log ind og godkend. Brugeren logger ind hos Google (hvis ikke allerede) og ser en samtykkeskærm, der lister, hvad appen beder om. De klikker Tillad.
4. Tilbage med en kode. Google omdirigerer browseren til appens redirect URI med en kortlivet, engangs authorization code.
5. Udveksling på serveren. Appens server sender koden plus sin klienthemmelighed direkte til Google og modtager et adgangstoken (og ofte et refresh token).
6. Brug API'et. Serveren kalder Google Kalender-API'et med adgangstokenet og henter brugerens begivenheder.

Callbacket i trin 4 ser nogenlunde sådan ud:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

Og token-svaret i trin 5 er JSON som:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Det vigtige designpunkt: tokenudvekslingen sker server-til-server, så klienthemmeligheden og tokens aldrig behøver at passere gennem browseren.

OAuth vs OpenID Connect vs dit eget login

Mange apps kombinerer dem: e-mail-og-adgangskode-login, plus „Log ind med Google“ via OIDC, plus separate OAuth-forbindelser til andre tjenester.

Centrale begreber

Almindelige misforståelser

• „OAuth er et login-system.“ Ren OAuth giver adgang; OpenID Connect håndterer identitet. At bruge et bart adgangstoken som bevis på, hvem nogen er, har givet reelle sikkerhedsfejl.
• „Appen får min adgangskode.“ Det gør den aldrig. Det er pointen.
• „At bede om flere scopes er harmløst.“ Brugere er mere skeptiske over for brede anmodninger, og udbydere som Google kan kræve en appgennemgang for følsomme eller restriktive scopes. Bed kun om det, du har brug for.
• „Klienthemmeligheden kan ligge i frontend.“ Alt i browserkode er offentligt. Hold den i server-side hemmeligheder.
• „Det virker i test, så det virker i produktion.“ Udbydere begrænser ofte ikke-verificerede apps – fx til listede testbrugere – og redirect-URI'en for dit live-domæne skal registreres separat.
• „Tokens holder for evigt.“ Adgangstokens udløber hurtigt, og brugere kan tilbagekalde adgang. Din app skal håndtere begge dele elegant.

Hvad du kan spørge din AI-builder om

• „Tilføj „Log ind med Google“ med OpenID Connect og et velvedligeholdt auth-bibliotek – skriv ikke OAuth-flowet selv.“
• „Brug authorization code-flowet med PKCE, og tjek state-parameteren.“
• „Læs client ID og client secret fra miljøvariabler på serveren.“
• „Anmod kun om de scopes, vi har brug for: skrivebeskyttet kalenderadgang.“
• „Fortæl mig alle redirect-URL'er, jeg skal registrere i udbyderens konsol – til preview, den udgivne URL og mit eget domæne.“
• „Gem refresh tokens krypteret i databasen, og håndtér udløbne eller tilbagekaldte tokens ved at bede brugeren forbinde igen.“
• „Lad brugere afbryde integrationen fra deres indstillingsside.“

OAuth og Mythex

Mythex har ikke indbygget slutbrugerlogin til de apps, du bygger; dokumentationen beskriver en bring-your-own-tilgang – du vælger et auth-bibliotek eller en hostet udbyder, gemmer dens nøgler som projekthemmeligheder, og agenten skriver koden. Opskriften til at tilføje autentificering har en startprompt til det. Du møder også OAuth i Mythex selv: du kan logge ind med Google, forbindelse til GitHub for repo-synkronisering bruger GitHub-OAuth, og AI-klienter, der forbinder til Mythex over MCP, går igennem en OAuth-samtykkeside. For mere, se hvad autentificering er og hvad to-faktor-autentificering er.

Spørgsmål