OAuth

OAuth?

OAuth staat voor Open Authorization en is een standaardprotocol waarmee je de ene applicatie toegang kunt verlenen tot gegevens of functionaliteit binnen een andere applicatie. OAuth gebruikt daarvoor digitale tokens zodat het niet nodig is om gebruikersnamen en wachtwoorden te delen tussen die applicaties. Dit maakt de samenwerking eenvoudiger en veiliger.

Wat is OAuth?

Je kunt met OAuth dus op een gestandaardiseerde manier autorisatie-instellingen vanaf één applicatie of dienst doorgeven aan een ander. Dat klinkt wat abstract maar je kunt het vergelijken met de keycard die je bij een hotel ontvangt bij het inchecken. De receptionist geeft jou als gast dan uiteraard niet de mastersleutel van het hotel mee. In plaats daarvan ontvang je een keycard met daarop exact jouw rechten. Je kunt net als iedere gast de voordeur openen, je hebt toegang tot je eigen kamer, en afhankelijk van je boeking bijvoorbeeld ook nog tot de fitnessruimte en de parkeergarage.

OAuth doet iets vergelijkbaar binnen digitale omgevingen. Een ‘authorization server’ verstrekt rechten aan een doelapplicatie door middel van een access token. De applicatie voor wie het token is bedoeld, ontvangt hiermee rechten voor specifieke gegevens en functies die via API’s bereikbaar zijn.

Hoe werkt OAuth?

Dit kunnen we het best illustreren aan de hand van het type toepassing waarvoor OAuth ooit is ontworpen. In het cloud tijdperk hebben applicaties vaak gegevens nodig die ergens anders in de cloud zijn opgeslagen. Of ze maken gebruik van features binnen andere systemen. Hoe kun je die gegevens en functionaliteit nu toegankelijk maken voor andere applicaties? Daarvoor zijn twee benaderingen: de conventionele oplossing voordat OAuth was ontwikkeld, en de oplossing met gebruik van OAuth.

Conventionele toegang tot online resources zónder OAuth

Neem het voorbeeld van een slimme online fotobewerking tool op internet. Die wil je gaan gebruiken om de foto’s te bewerken die je bewaart op je Google Drive. De applicatie moet daarvoor toegang krijgen tot je Google Drive en in het ‘pre-OAuth’ tijdperk gebeurde dat door vanuit de applicatie via een API rechtstreeks in te loggen op je Google account. Daarvoor moet dan jouw gebruikersnaam en wachtwoord worden gebruikt en het resultaat ervan is dat de applicatie toegang krijgt tot jouw foto’s, maar ook tot alle andere functionaliteit en gegevens binnen je Google account. Dat is niet wat je wilt en daarom is OAuth ontwikkeld.

Toegang tot online resources mét OAuth

Met OAuth is het niet langer nodig om binnen die applicatie in te loggen op je Google account. In plaats daarvan krijg je een melding dat de applicatie toegang wil krijgen tot je Google Drive-foto’s, en dat je moet inloggen op je Google account om daarvoor toestemming te geven.

Als je dan inlogt op je account krijg je automatisch de vraag of je de applicatie toestemming wilt geven om foto’s op je Drive te kunnen bewerken. Als je dat verzoek bevestigt, verstuurt Google – die hier dus fungeert als authorization server – een access token naar de betreffende applicatie. Daarmee krijgt die toegang tot je Google account, maar wel alleen om de foto’s te bekijken en te bewerken. Verdere toegang blijft geblokkeerd.

Voor de gebruikers lijken de scenario’s op elkaar, want in beide gevallen log je in met je Google gegevens. Maar zonder OAuth gebeurt dit ‘binnen’ de applicatie en zet je hiermee automatisch direct de deur open naar al jouw gegevens. Met OAuth log je op de reguliere manier in op je Google account, en verstrek je de applicatie alleen een specifiek recht: foto’s bekijken en bewerken.

Voordelen van OAuth?

Hiermee realiseert OAuth meerdere voordelen:

• We kunnen autorisaties aan systemen verstrekken zonder dat we daarvoor iemands wachtwoord hoeven te delen. Zo is er een heldere scheiding tussen de authenticatie van een gebruiker en welke autorisaties worden verstrekt.

• We hebben nu een mechanisme voor fijnmazige autorisatie. Bij het gebruik van iemands persoonlijke inloggegevens ontvangt een applicatie ook automatisch iemands volledige set rechten. Met OAuth kun je veel specifiekere autorisaties instellen. Rechten zijn ook weer eenvoudig in te trekken zonder het wachtwoord te hoeven veranderen.

• Er is nu een standaard protocol dat kan worden gebruikt tussen verschillende type systemen en applicaties, van verschillende leveranciers en dienstverleners.

• We vereenvoudigen het beheer van toegangsrechten omdat we gedetailleerde toegangsrechten voor meerdere systemen vanaf één plek kunnen instellen.

Voorbeelden van OAuth in de praktijk

Er zijn talloze voorbeelden van het gebruik van OAuth maar het is vooral nuttig om daarbij onderscheid te maken tussen twee type scenario’s. We geven van allebei een voorbeeld.

Type 1 toepassing: Gedelegeerde autorisaties

Het eerder genoemde scenario met de fotobewerking toepassing is een voorbeeld waar OAuth alleen wordt gebruikt om specifieke rechten te delegeren naar andere applicaties. Bij de fotobewerking applicatie krijg je dan als gebruiker bijvoorbeeld onderstaande prompt getoond:

“Deze app wil toegang tot foto’s op je Google Drive. Log in bij Google en geef toestemming om je foto’s te gebruiken.”

Door vervolgens in te loggen op je Google Account en het verzoek te bevestigen geef je die toestemming. De applicatie ontvangt vervolgens een access token met de exacte rechten, maar weet verder niets van de gebruiker. Er zijn geen identiteitsgegevens gedeeld, het is zuiver een technische toegang tot online resources.

Type 2 toepassing: Gedelegeerde authenticatie (bijvoorbeeld Single Sign-On)

OAuth wordt tegenwoordig echter ook gebruikt om bijvoorbeeld Single Sign-On (SSO) scenario’s te ondersteunen. Stel dat je de fotobewerking applicatie niet ad hoc wil gebruiken, maar een account neemt zodat je meer mogelijkheden hebt. De traditionele aanpak is dat je hiervoor een account moet aanmaken, je persoonsgegevens invult en een wachtwoord instelt. Gelukkig zijn er tegenwoordig eenvoudiger oplossingen, bijvoorbeeld door in te loggen via Google of een ander social media account. In dat geval geeft de applicatie een melding met deze strekking:

"Deze app wil je identiteit gebruiken om je in te loggen. Log in bij Google en geef toestemming om je naam, e-mailadres en profielinformatie te delen."

Dit is handig want je hoeft niet voor deze account een aparte gebruikersnaam en wachtwoord te gebruiken. Zodra je bent ingelogd op Google, heb je ook als geregistreerde gebruiker toegang tot de applicatie. Dit mechanisme is beschikbaar met allerlei particuliere accounts (Google, Microsoft, Facebook etc.)

Ook binnen organisaties wordt intensief gebruik gemaakt van zulke SSO functionaliteit. Daarbij wordt gebruik gemaakt van een zogeheten Identity Provider zoals Google Workspace, Microsoft Active Directory of Entra ID. Ook IAM leveranciers zoals HelloID beschikken over een ingebouwde Identity Provider.

Verschil tussen gedelegeerde autorisatie en authenticatie

Bij de eerste toepassing gebruikte je OAuth dus op de oorspronkelijke manier. Door middel van een token verleen je toegang tot specifieke technische resources. De identiteit van de gebruiker speelt daarbij geen rol.

In het tweede scenario gebruik je OAuth om ook identiteitsgegevens te delen. Daarvoor is een extra authenticatie-laag ontwikkeld als aanvulling op OAuth. Die authenticatie-laag is OpenID Connect (OIDC).

OAuth 2.0

Bij de voorgaande voorbeelden hebben we het overigens over OAuth 2.0. De eerste versie van OAuth is ontwikkeld in 2007. Deze ondersteunde alleen websites en was nog grotendeels gebaseerd op proprietary protocollen van onder andere Google. In 2012 is OAuth 2.0 gelanceerd dat veel krachtiger is en ook applicaties en mobiele apps ondersteunt. Voor deze versie hebben veel meer grote technologiespelers input geleverd en dat resulteerde in een compleet herontwerp. Ook is niet lang na de release van OAuth 2.0 de OpenID Connect laag toegevoegd ten behoeve van de authenticatie.

OAuth versus OIDC

OpenID Connect (OIDC) is dus aanvullende functionaliteit die is toegevoegd aan OAuth om ook identiteitsgegevens te delen. De basisflows ten behoeve van autorisatie en authenticatie zijn daarbij vergelijkbaar, maar de verstuurde informatie verschilt. In plaats van een access token met autorisaties, wordt er ten behoeve van identiteitsgegevens een ID token verstuurd. En waar de access tokens worden aangemaakt in de authorization server, wordt het ID token gegenereerd in een OIDC-provider.

Dit zijn overigens de functionele termen, hoe de functionaliteit in de praktijk wordt ingebouwd, verschilt per leverancier. De essentie is dat je met OAuth autorisaties centraal kunt verstrekken en met OIDC iemands identiteit vanuit één plek kan bevestigen. In een SSO-scenario moet iemand aan de start van een sessie eenmalig inloggen met bijvoorbeeld een wachtwoord en Multi-Factor Authenticatie. Als de gebruiker tijdens de gebruikerssessie een of meerdere applicaties gebruikt, wordt de identiteit steeds direct bevestigd zonder apart in te loggen. ‘Onder de motorkap’ gebeurt dit met behulp van het ID token.

OAuth versus SAML

OAuth wordt nogal eens vergeleken met SAML (Security Assertion Markup Language). Waar OAuth primair is ontwikkeld voor cloudapplicaties en mobiele toepassingen, richtte SAML zich van origine op zakelijke toepassingen. Ook is SAML minder bedoeld voor het verstrekken van autorisaties zoals OAuth. Met SAML kun je weliswaar basaal rechten instellen maar de belangrijkste functie van SAML ligt in authenticatie en SSO.

Qua functionaliteit is SAML is dus vooral te vergelijken met OIDC. Beiden SSO-oplossingen worden in de praktijk toegepast binnen professionele IAM omgevingen en bijvoorbeeld de HelloID Access Management module ondersteunt beide technologieën.

HelloID ondersteuning van OAuth

Meer weten over het gebruik van OAuth (en specifiek OIDC) binnen het HelloID platform? Je vindt er alles over in dit artikel.