OAuth

OAuth 1.0 begyndte som en fællesskabsspecifikation i 2007 og blev udgivet som RFC 5849 i 2010; hver forespørgsel blev signeret med klientens og tokenets hemmeligheder. OAuth 2.0 (RFC 6749, oktober 2012) droppede signering af forespørgsler til fordel for bearer-tokens beskyttet af TLS (RFC 6750) og blev et rammeværk frem for én enkelt protokol. RFC 6749 §1.1 definerer fire roller: ressourceejer, klient, autorisationsserver (AS) og ressourceserver (RS). Den definerer fire grant-typer: authorization code (§4.1), implicit (§4.2), resource owner password credentials (§4.3) og client credentials (§4.4) samt refresh-tokens (§6). Senere RFC'er tilføjede device authorization grant til enheder med begrænset input (RFC 8628), token exchange (RFC 8693) og vejledning til native apps (RFC 8252).

Authorization code-flowet med PKCE er nu standardvalget for næsten alle klienter. Klienten genererer en tilfældig code_verifier og sender browseren til AS'ens authorize-endpoint med response_type=code, client_id, en præcist registreret redirect_uri, det ønskede scope, en state-værdi mod CSRF og en code_challenge, som er SHA-256-hashen af verifieren (RFC 7636, metoden S256). Når brugeren har autentificeret sig og givet samtykke, sender AS'en browseren tilbage med en kortlivet engangskode. Klienten indløser koden på token-endpointet med code_verifier og, hvis den er fortrolig, sin klientautentificering, og modtager et adgangstoken, som regel sammen med et refresh-token. Da verifieren aldrig har været gennem browseren, kan en opsnappet kode ikke indløses.

RFC 9700, OAuth 2.0 Security Best Current Practice (januar 2025), samler erfaringerne: PKCE for alle klienter, eksakt strengsammenligning af redirect-URI'er, ingen implicit grant og ingen password grant, rotation eller afsenderbinding af refresh-tokens for offentlige klienter og forsvar mod mix-up-angreb som iss-parameteren i svaret (RFC 9207). Afsenderbundne tokens binder tokenet til en nøgle, klienten har, via gensidig TLS (RFC 8705) eller DPoP (RFC 9449), så et stjålet token ikke er nok alene. Adgangstokens kan være uigennemsigtige og kontrolleres via introspektion (RFC 7662) eller være selvindeholdte JWT'er (RFC 9068); tilbagekaldelse er standardiseret i RFC 7009. Arbejdet med OAuth 2.1 samler denne praksis i ét konsolideret dokument.

OAuth er delegeret autorisation, ikke autentificering. Et adgangstoken er rettet mod ressourceserveren, så en klient, der opfatter "jeg har fået et token" som bevis for, hvem brugeren er, kan narres med et token, der er udstedt til en anden applikation; OpenID Connects audience-bundne ID-token lukker det hul. Andre tilbagevendende problemer er for brede scopes, langlivede refresh-tokens, der opbevares usikkert, lækkede koder via åbne redirects eller Referer-headere og ulovlige samtykker (illicit consent grants), hvor brugere narres til at godkende en app, som angriberen har registreret, med adgang til mail eller filer; derfor begrænser mange tenants brugernes samtykke til verificerede udgivere eller rettigheder med lav risiko.