OAuth (Open Authorization) is een open standaard voor autorisatie.

Gebruikers kunnen hiermee een programma of website toegang geven tot hun privégegevens, die opgeslagen zijn op een andere website, zonder hun gebruikersnaam en wachtwoord uit handen te geven.

OAuth maakt gebruik van tokens, waardoor vertrouwelijke gegevens als een gebruikersnaam of wachtwoord niet afgegeven hoeven te worden. Elk token geeft slechts toegang tot specifieke gegevens van één website voor een bepaalde duur. Zo kan ingesteld worden dat een bepaald programma slechts een jaar toegang heeft tot de gegevens. Hierna kan eventueel opnieuw toegang worden gevraagd.

Flow van 'authorisation code' profiel

De flow van het 'authorisation code'-profiel ziet er in grote lijnen als volgt uit:

Bron: surf.nl

Onderaan zie je gebruikers die via een app (bijvoorbeeld op een mobiel device) toegang willen tot een datastore of API van hun instelling. In OAuth-termen heet zo’n datastore of API een “Resource Server” (RS). Deze resource server levert (gefilterde) resources uit de backendsystemen van de instelling.

Daarnaast zie je een zogenaamde “Authorization Server” (AS) die alle OAuth-berichten afhandelt. Deze is in dit geval gekoppeld aan een identiteitsfederatie om de inkomende gebruikers te kunnen authenticeren.

Wat gebeurt er nu als een gebruiker data wil opvragen uit de resource server?

Zijn client vraagt dan eerst de Authorization Server om een “authorization code” (1). Voordat de Authorization Server die kan uitgeven, moet hij eerst weten wie de gebruiker is voor wie de code moet worden uitgegeven. Om dat vast te stellen moet de gebruiker zich eerst authenticeren (2).

Na succesvolle authenticatie vraagt de Authorization Server de gebruiker dan om toestemming om de betreffende app toegang te geven tot de gevraagde gegevens. Slechts als de gebruiker deze toestemming verleent, geeft de AS de client een authorization code terug (3). De client kan de authorization code bij de Authorization Server inwisselen voor een “access token”, waarmee hij voortaan (zonder al deze stappen opnieuw te doorlopen) toegang krijgt tot de daadwerkelijke data-interface.

Merk op dat het hiermee mogelijk wordt om eenmalig een account te “koppelen” binnen een mobiele app, waarna die mobiele app voortaan in de achtergrond toegang krijgt tot de gevraagde data, zonder dat de gebruiker telkens opnieuw moet inloggen.

Als de client nu daadwerkelijk data wil gaan ophalen, spreekt hij de API van de resource server aan, en geeft daarbij het ontvangen access token mee (4). De resource server controleert vervolgens bij de Authorization Server of het access token geldig is (5), en de Authorization server vertelt hem bovendien bij welke gebruiker dit token hoort, en in welke context (bijv. voor welke interface) het is afgegeven. Op basis daarvan kan de Resource Server beslissen tot welke data de client toegang krijgt in de backend (7), en of hij de gevraagde data terug wil geven aan de client (8).