Hvad betyder OAuth?
OAuth er en standard for delegeret adgang. Når en virksomhed forbinder et automatiseringsværktøj med eksempelvis en kalender, kan brugeren eller administratoren godkende bestemte rettigheder hos kalenderudbyderen. Værktøjet får derefter et adgangstoken, som bruges ved efterfølgende API-kald.
Det centrale spørgsmål er, hvad forbindelsen må gøre, på hvis vegne og hvor længe. OAuth er primært autorisation: retten til at bruge en ressource. Det er ikke i sig selv en fuld standard for at bevise brugerens identitet ved login. Den forskel betyder noget, når samme integration både skal kende medarbejderen og udføre handlinger.
Forstå hvem der giver hvilken adgang
Et typisk forløb har en ressourceejer, en applikation, en autorisationsserver og et API, som beskytter dataene. Applikationen anmoder om scopes, altså afgrænsede adgangsområder. Brugeren godkender gennem udbyderens eget flow, hvorefter applikationen kan få tokens. Et scope som læsning af kalender er væsentligt anderledes end retten til at oprette og slette aftaler. Sammenhold derfor godkendelsesskærmens rettigheder med den konkrete opgave. Adgang bør ikke udvides, alene fordi en standardforbindelse tilbyder en nemmere opsætning med flere rettigheder.
Tokens skal også kunne udløbe og tilbagekaldes
Et adgangstoken er en følsom adgangsbillet. Afhængigt af løsningen kan et refresh token bruges til at hente nye adgangstokens. Begge dele kræver kontrolleret opbevaring og en plan for tilbagekaldelse. Den aktuelle OAuth-sikkerhedsvejledning beskriver blandt andet authorization code og PKCE til beskyttelse af kodeudvekslingen. Brug udbyderens vedligeholdte bibliotek og relevante aktuelle flow i stedet for at kopiere et gammelt login-eksempel. Forretningen bør samtidig vide, hvad der sker, når en medarbejder forlader virksomheden, en godkendelse trækkes tilbage eller forbindelsen skal genetableres.
Et eksempel fra praksis
En mødeassistent skal foreslå ledige tidspunkter og oprette aftaler efter en medarbejders godkendelse. Projektet starter med et rettighedskort: hvilke kalendere må læses, hvem kan oprette en aftale, og hvilke data må gemmes? I testen tilbagekalder administratoren forbindelsen. Assistenten skal derefter stoppe med en tydelig status og undlade at påstå, at en aftale er booket. Testen af tilbagekaldelse er lige så relevant som den første vellykkede forbindelse.
Typiske faldgruber
- At forveksle et godkendt OAuth-flow med tilladelse til enhver senere handling.
- At skrive tokens i almindelige logs, prompts eller fejlmeddelelser.
- At lade en vigtig integration afhænge af en fratrådt medarbejders personlige forbindelse.
Det skal I afklare
- Dokumentér scopes, ressourceejer og de konkrete API-handlinger, der er nødvendige.
- Vælg et aktuelt udbyderunderstøttet flow og beskyttelse af tokens.
- Test udløb, tilbagekaldelse og genforbindelse med en tydelig ansvarlig.
Spørgsmål og svar
Er OAuth det samme som at logge ind med Google?
Ikke helt. Login kan bruge OpenID Connect oven på OAuth. OAuth-delen vedrører adgang, mens identitetslaget hjælper applikationen med at verificere, hvem brugeren er.
Er en OAuth-forbindelse altid sikker?
Nej. For brede rettigheder, lækkede tokens eller fejl i implementeringen kan stadig give problemer. Standarden skal bruges korrekt og indgå i en samlet adgangsstyring.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- IETF: OAuth 2.0 Authorization Framework ↗Roller, adgangstokens og afgrænset autorisation.
- IETF: Best Current Practice for OAuth 2.0 Security ↗Aktuelle sikkerhedsanbefalinger, herunder authorization code og PKCE.
- OpenID Foundation: OpenID Connect Core ↗Identitetslaget oven på OAuth og adskillelsen mellem login og adgang.