OAuth 2.0 hedder i RFC 6749 "The OAuth 2.0 Authorization Framework". Ordet autorisation står i titlen, og det er ikke tilfældigt. OAuth 2.0 handler om at give en klient lov til at gøre noget bestemt på en brugers vegne. Det handler ikke om at fastslå, hvem brugeren er.
Fire roller og ét token
Der er fire roller: resource owner, altså brugeren, resource server, som ligger inde med data, client, som vil have fat i dem, og authorization server, som udsteder tokens.
Resultatet er et access token. Det repræsenterer en adgangsret til bestemte ressourcer, i et bestemt omfang, i et bestemt tidsrum. Det er alt, hvad det repræsenterer. Der er ikke noget standardiseret i et access token, der fortæller, hvem personen bag er.
Den klassiske fejl
Fejlen ser sådan her ud. Udvikleren sender brugeren gennem et OAuth-flow, får et access token tilbage, kalder udbyderens profil-API med tokenet, får en e-mailadresse og et navn, og opretter så en session med den bruger. Login, tænker man.
Det er usikkert, og grunden er enkel. Tokenet er bare en streng, som din applikation har fået udleveret. Den siger ikke, hvem den blev udstedt til. Et token, der er udstedt til en helt anden klient, ser præcis lige så gyldigt ud, når du sender det mod profil-API'et. Får en angriber fingre i et sådant token fra en anden app, kan det bruges til at logge ind som offeret hos dig.
Det er netop det hul, OpenID Connect lukker. ID-tokenet er signeret og har et aud-claim, som skal indeholde din egen client_id. Passer den ikke, afviser du. Uden det tjek findes der ingen kobling mellem tokenet og din applikation.
Client credentials
§ 4.4 i RFC 6749 beskriver client credentials grant. Her handler klienten på egne vegne, uden en slutbruger overhovedet. Server til server. Der udstedes ikke refresh token, fordi klienten bare kan hente et nyt token med sine egne oplysninger.
Det er den rigtige type til baggrundskald, fx når dit system henter status på en igangsat kontrol. Skal du derimod vide, at det faktisk er Hansen, der sidder i den anden ende, fordi du laver aldersverifikation eller KYC, er OAuth 2.0 alene det forkerte værktøj. Du skal bruge et lag, der udtaler sig om identiteten.