Definitie: OAuth 2.0 is een open standaard voor autorisatie waarmee een applicatie namens een gebruiker toegang krijgt tot gegevens of functies in een ander systeem, zonder dat de gebruiker zijn wachtwoord deelt. In plaats van een wachtwoord krijgt de applicatie een tijdelijk access token met beperkte rechten.
In het kort
- OAuth 2.0 verscheen in 2012 als opvolger van OAuth 1.0 en is vastgelegd in RFC 6749; het is de gangbare standaard voor toegang tot API’s.
- OAuth regelt autorisatie (wat mag een app), niet authenticatie (wie is de gebruiker); daarvoor wordt OpenID Connect gebruikt, dat op OAuth 2.0 voortbouwt.
- Er zijn vier rollen: resource owner, client, authorization server en resource server.
- De authorization code flow, bij voorkeur met PKCE, is de aanbevolen route voor web- en mobiele apps; de client credentials flow is bedoeld voor communicatie tussen systemen.
Wat is OAuth?
Stel dat een planningsapp afspraken in je Google-agenda wil zetten. Vroeger zou de app je Google-wachtwoord vragen. Dat is riskant: de app kan dan alles in je account, en als je de app wilt afsluiten, moet je je wachtwoord veranderen.
OAuth lost dat op. De app stuurt je door naar Google. Daar log je zelf in en zie je welke toegang de app vraagt, bijvoorbeeld alleen je agenda lezen en bewerken. Geef je toestemming, dan krijgt de app een access token: een soort tijdelijke sleutel die alleen toegang geeft tot wat jij hebt goedgekeurd. Je wachtwoord ziet de app nooit, en je kunt de toegang later intrekken zonder je wachtwoord te wijzigen.
Developer Overheid beschrijft OAuth 2.0 precies zo: een open standaard waarmee een app namens een gebruiker toegang krijgt tot gegevens of functies, zonder dat het wachtwoord wordt gedeeld. De standaard is vastgelegd in RFC 6749. Auth0 noemt OAuth 2.0 de de-factostandaard voor online autorisatie sinds het in 2012 OAuth 1.0 verving.
Welke rollen kent OAuth 2.0?
| Rol | Wie of wat | Voorbeeld |
|---|---|---|
| Resource owner | De eigenaar van de gegevens, meestal de gebruiker | Jij, met je agenda |
| Client | De applicatie die toegang wil | De planningsapp |
| Authorization server | Controleert de gebruiker en geeft tokens uit | De inlogdienst van Google |
| Resource server | De API die de gegevens beschermt | De agenda-API van Google |
Soms zijn authorization server en resource server onderdeel van hetzelfde systeem, maar de rollen blijven verschillend.
Hoe werkt OAuth 2.0 stap voor stap?
De meest gebruikte route is de authorization code flow:
- Verzoek. De gebruiker klikt in de app op bijvoorbeeld “Koppel je agenda”. De app stuurt hem door naar de authorization server, met daarbij welke rechten (scopes) worden gevraagd.
- Inloggen en toestemming. De gebruiker logt in bij de authorization server en ziet welke toegang de app vraagt. Hij geeft toestemming of weigert.
- Code. De authorization server stuurt de gebruiker terug naar de app, met een eenmalige autorisatiecode.
- Token. De app wisselt die code op de achtergrond in voor een access token, en vaak ook een refresh token.
- Toegang. De app gebruikt het access token bij elke aanroep van de API. De API controleert het token en geeft alleen toegang tot de toegestane gegevens.
- Vernieuwen. Verloopt het access token, dan haalt de app met het refresh token een nieuw token op, zonder dat de gebruiker opnieuw hoeft in te loggen.
Tokens en scopes
| Begrip | Betekenis |
|---|---|
| Access token | Tijdelijke sleutel waarmee de app de API aanroept; vaak een JWT, soms een willekeurige code |
| Refresh token | Langer geldig, om nieuwe access tokens op te halen; moet veilig op de server worden bewaard |
| Scope | De omschrijving van de gevraagde rechten, zoals alleen lezen of ook schrijven |
| Autorisatiecode | Eenmalige code die wordt ingeruild voor tokens |
| ID-token | Onderdeel van OpenID Connect; vertelt wie de gebruiker is |
Woensdag waarschuwt dat scopes de gevraagde toegang beperken, maar geen vervanging zijn voor controle in de API zelf. Ook moet een ID-token nooit als access token worden gebruikt: het ID-token is bedoeld voor de app, het access token voor de API.
Welke flows (grant types) zijn er?
| Flow | Wanneer | Status |
|---|---|---|
| Authorization code | Webapplicaties met een eigen server | Aanbevolen |
| Authorization code met PKCE | Mobiele apps en single page applications | Aanbevolen |
| Client credentials | Systeem-naar-systeemkoppelingen zonder gebruiker | Aanbevolen voor die situatie |
| Device authorization | Apparaten zonder toetsenbord, zoals smart-tv’s | Voor specifieke gevallen |
| Implicit | Vroeger voor browser-apps | Afgeraden, tokens kunnen lekken |
| Resource owner password | App vraagt direct het wachtwoord | Alleen voor volledig vertrouwde clients, verouderd |
PKCE (uitgesproken als “pixie”) voegt een extra controle toe: de app maakt vooraf een geheime waarde aan en bewijst bij het inwisselen van de code dat hij het oorspronkelijke verzoek deed. Een onderschepte code is dan waardeloos. Het Nederlandse overheidsprofiel voor OAuth schrijft PKCE strikt voor.
OAuth vs OpenID Connect: wat is het verschil?
| OAuth 2.0 | OpenID Connect | |
|---|---|---|
| Doel | Autorisatie: wat mag een app namens de gebruiker | Authenticatie: wie is de gebruiker |
| Resultaat | Access token | ID-token, naast een access token |
| Typisch gebruik | Toegang tot API’s van andere systemen | Inloggen met een bestaand account, zoals “Inloggen met Google” |
| Relatie | Basisstandaard | Bouwt voort op OAuth 2.0 |
Developer Overheid benadrukt dat OAuth zelf niet authenticeert. Wil je weten wie er inlogt, dan gebruik je OpenID Connect, dat een ID-token toevoegt met de identiteit van de gebruiker.
OAuth, API-sleutels en wachtwoorden vergeleken
Niet elke koppeling gebruikt OAuth. Veel systemen werken ook met een vaste API-sleutel. De verschillen:
| Wachtwoord delen | API-sleutel | OAuth 2.0 | |
|---|---|---|---|
| Wat krijgt de app | Volledige toegang tot het account | Een vaste sleutel, vaak met brede rechten | Een tijdelijk token met afgebakende rechten |
| Geldigheid | Tot het wachtwoord wijzigt | Meestal tot de sleutel wordt ingetrokken | Kort, met vernieuwing via een refresh token |
| Toestemming van gebruiker | Impliciet | Door een beheerder ingesteld | Expliciet, per app en per scope |
| Intrekken | Wachtwoord wijzigen, alle koppelingen stoppen | Sleutel vervangen | Per app intrekken, zonder gevolgen voor andere koppelingen |
| Geschikt voor | Niet aan te raden | Eenvoudige koppelingen tussen eigen systemen | Toegang namens gebruikers en externe diensten |
Een API-sleutel is eenvoudig en prima voor een interne koppeling tussen twee systemen die je zelf beheert. Zodra een app namens verschillende gebruikers toegang krijgt tot hun gegevens in een ander systeem, is OAuth de logische keuze.
Toegang beheren en intrekken
Een groot voordeel van OAuth is dat toegang zichtbaar en beheersbaar is. Bij de meeste diensten zie je in je accountinstellingen welke apps toegang hebben en welke rechten ze hebben. Daar kun je de toegang van één app intrekken zonder je wachtwoord te wijzigen. Volgens Serviceware zijn access tokens in tijd beperkt en kunnen tokens bij misbruik worden ingetrokken.
Voor een organisatie betekent dat ook een beheertaak. Leg vast welke koppelingen er zijn, onder welk account ze zijn gemaakt en wie ze beheert. Vertrekt een medewerker die een koppeling onder zijn eigen account heeft aangemaakt, dan kan die koppeling ineens stoppen. Gebruik daarom bij voorkeur een account van de organisatie of een servicekoppeling via de client credentials flow.
OAuth in Nederland
Voor de Nederlandse overheid bestaat het NL GOV OAuth-profiel, een afsprakenkader voor veilig en uitwisselbaar gebruik van OAuth tussen overheidssystemen. Het profiel is gebaseerd op RFC 6749 en sluit aan bij de actuele beveiligingsaanbevelingen. Daarnaast werkt de internationale standaardorganisatie aan OAuth 2.1, dat de best practices van de afgelopen jaren bundelt.
Waar kom je OAuth tegen?
- Inloggen met een bestaand account, zoals Google of Microsoft, via OpenID Connect.
- Koppelingen met online diensten, zoals agenda’s, boekhoudpakketten, CRM’s en advertentieplatforms.
- Eigen API’s die je beschikbaar stelt aan partners of aan je eigen mobiele app.
- Koppelingen tussen systemen binnen een organisatie, via de client credentials flow.
Veelgemaakte fouten
- Te brede scopes vragen. Vraag alleen de rechten die nodig zijn; een gebruiker vertrouwt een app die weinig vraagt eerder.
- Tokens onveilig bewaren. Refresh tokens horen versleuteld op de server, niet in de browser.
- Redirect-adressen niet exact vastleggen. Woensdag raadt af om jokertekens te gebruiken in toegestane terugkeeradressen.
- De state-parameter overslaan, waardoor een aanvaller een loginverzoek kan manipuleren.
- Verlopen tokens niet afhandelen. Een koppeling die stopt zodra een token verloopt, zorgt voor stille fouten.
- OAuth gebruiken voor pure identificatie zonder OpenID Connect.
Wat betekent dit voor jouw project?
Marketooo, het platform dat ik in actieve ontwikkeling heb voor marketingprocessen, gebruikt OAuth om accounts te koppelen, onder meer voor Meta Ads. De bouwles daar: maak verantwoordelijkheden zichtbaar voordat een systeem iets uitvoert. Een campagne moet bij het juiste account horen, en de gebruiker moet weten welke toegang hij geeft.
Bij een koppeling met een ander systeem onderzoek ik eerst of een bestaand pakket, een koppeling of maatwerk het beste past. Ondersteunt het andere systeem OAuth, dan is dat meestal de veiligste route.
Vraag? Wil je twee systemen veilig laten samenwerken? Stuur me welke systemen het zijn en welke gegevens over en weer moeten. Dan bepalen we samen de logische eerste stap.
Veelgestelde vragen over OAuth
Wat is OAuth?
OAuth is een open standaard voor autorisatie waarmee een applicatie namens een gebruiker toegang krijgt tot gegevens in een ander systeem, zonder het wachtwoord van de gebruiker te kennen. De app krijgt een tijdelijk access token met beperkte rechten.
Wat is het verschil tussen OAuth en OAuth 2.0?
OAuth 2.0 is de opvolger van OAuth 1.0 en verscheen in 2012. Het is een herschreven standaard met eenvoudiger tokens en meerdere flows voor verschillende soorten apps, en wordt tegenwoordig vrijwel overal gebruikt.
Is OAuth hetzelfde als inloggen?
Nee. OAuth regelt wat een app mag doen namens een gebruiker, niet wie de gebruiker is. Voor inloggen wordt OpenID Connect gebruikt, dat op OAuth 2.0 voortbouwt en een ID-token toevoegt.
Verwante termen
API-koppeling · Backend · Privacy by design · OWASP Top 10 · Klantportaal · Workflow-automatisering
← Terug naar de kennisbank