Hvad er OAuth 2.0?
OAuth 2.0 er den åbne standard for delegeret adgang: Den lader en applikation bruge en afgrænset del af jeres data hos en anden tjeneste, uden at I nogensinde udleverer jeres password til applikationen. Standarden blev udgivet af IETF i 2012 som RFC 6749 og er i dag fundamentet under stort set alle integrationer mellem cloud-tjenester.
Før OAuth var alternativet grumt: Ville et regnskabsprogram læse jeres bankdata, skulle det have jeres netbank-login. Med OAuth godkender I i stedet adgangen hos banken, og programmet får et token, der kun kan dét, I sagde ja til.
Hvordan virker det?
Fire roller spiller sammen: brugeren, applikationen (klienten), autorisationsserveren (fx Microsoft Entra ID) og tjenesten med dataene. Forløbet:
- Applikationen sender brugeren til autorisationsserveren.
- Brugeren logger ind dér (MFA og betinget adgang gælder) og ser en samtykkeskærm: "Appen beder om adgang til at læse din kalender".
- Godkendes det, får applikationen et adgangstoken: tidsbegrænset og afgrænset til de godkendte rettigheder, kaldet scopes.
- Applikationen bruger tokenet mod tjenesten. Passwordet så den aldrig.
Tokens udløber hurtigt og kan trækkes tilbage centralt, i skarp kontrast til et delt password, der virker, til nogen husker at skifte det.
OAuth, OpenID Connect og OAuth 2.1
En vigtig præcisering: OAuth er autorisation ("hvad må appen?"), ikke autentifikation ("hvem er brugeren?"). Til login-delen bruges OpenID Connect (OIDC), et identitetslag bygget oven på OAuth. Det er kombinationen, der driver "Log ind med Microsoft" og federation på tværs af tjenester, og som giver SSO-oplevelsen.
Standarden vedligeholdes løbende: OAuth 2.1 er under færdiggørelse i IETF og samler ti års sikkerhedserfaring i ét dokument: bl.a. obligatorisk PKCE-beskyttelse og fjernelse af de usikre gamle flows (implicit og password grant). Moderne identitetsplatforme følger allerede kravene.
Risikoen: consent phishing
OAuths samtykkemodel har en bagside, som angribere aktivt udnytter: consent phishing. I stedet for at stjæle passwordet lokker en phishing-mail brugeren til at godkende en ondsindet app ("HR-dokument, klik for at åbne"), og appen beder om adgang til mail og filer. Godkender brugeren, har angriberen et gyldigt token, og hverken passwordskifte eller MFA hjælper, før app-samtykket trækkes tilbage. Forsvaret er centralt: Begræns, hvilke apps brugere selv må godkende i jeres Microsoft 365-miljø, kræv admin-godkendelse for resten, og gennemgå eksisterende app-adgange regelmæssigt.
Sådan hjælper MI Support IT
Vi styrer og overvåger app-adgange i kunders Microsoft 365-miljøer: fornuftige samtykkepolitikker i Entra ID, oprydning i gamle app-tilladelser og overvågning af mistænkelige godkendelser, som del af jeres samlede IT-sikkerhed. Kontakt os, hvis I aldrig har gennemgået, hvilke apps der har adgang til jeres data.