Is OAuth hetzelfde als authenticatie?

Nee. OAuth is autorisatie: het verleent de client toestemming om toegang te krijgen tot bronnen. OpenID Connect, gebouwd op OAuth, voegt authenticatie toe. "Aanmelden met Google" is OIDC; 'Verbind Google Agenda' kan afhankelijk zijn van de vraag of de app moet weten wie u bent of alleen toegang tot uw gegevens nodig heeft.

Moet ik OAuth gebruiken of wachtwoorden opslaan?

Gebruik OAuth waar mogelijk. Het opslaan van gebruikerswachtwoorden betekent dat u alle verantwoordelijkheid overneemt voor hashing, salt, reactie op inbreuken, wachtwoordherstel en 2FA. Door via OAuth te delegeren naar Google/Apple/Microsoft/GitHub wordt dat allemaal ontlast. Het nadeel is dat uw gebruikers accounts bij die providers nodig hebben.

Waarom kunnen OAuth-tokens worden ingetrokken, maar wachtwoorden niet?

Tokens verwijzen naar een vermelding in de database van de autorisatieserver. Als u de invoer intrekt, wordt het token onmiddellijk ongeldig. Wachtwoorden zijn kennis: u kunt het wachtwoord roteren en herauthenticatie afdwingen, maar het oude wachtwoord blijft geldig totdat u dat doet.

Wat is het verschil tussen OAuth 2.0 en OAuth 1.0?

OAuth 1.0 (2007) gebruikte bij elk verzoek cryptografische handtekeningen. OAuth 2.0 (2012) vertrouwt op TLS voor transportbeveiliging en gebruikt dragertokens. OAuth 2.0 is eenvoudiger te implementeren en wordt in vrijwel elke moderne API geleverd; OAuth 1.0 is feitelijk verouderd.

Zijn OAuth-tokens gevaarlijk als ze lekken?

Ja: iedereen met het token heeft de verleende toegang totdat deze verloopt of wordt ingetrokken. Oplossingen: korte levensduur van toegangstokens (normaal 1 uur), vernieuwingstokens veiliger opgeslagen, minimalisering van de scope, auditlogboekregistratie. Behandel toegangstokens tijdens hun geldigheidsduur met dezelfde zorg als wachtwoorden.

OAuth 2.0 uitgelegd: hoe "Aanmelden met Google" eigenlijk werkt

Elke knop 'Aanmelden met Google', elke link 'Verbind je Twitter-account', elke API-integratie tussen moderne services verloopt via OAuth. Het protocol vervangt het delen van wachtwoorden door een stroom van tokens en toestemmingsschermen, en het begrijpen van de bewegende delen demystificeert een categorie van aanvallen en gemakken.

De volledige artikeltekst vindt u hieronder in het Engels.

OAuth 2.0 is een autorisatieframework waarmee een applicatie namens een gebruiker beperkte toegang kan krijgen tot de bronnen van een andere applicatie - zonder ooit het wachtwoord van de gebruiker te zien. De klassieke gebruikssituatie: voor een agenda-app die uw Google Agenda moet lezen, hoeft u niet uw Google-wachtwoord op te geven. Met OAuth kunt u de app in plaats daarvan een herroepbaar token toekennen.

De actoren

Vier rollen in een OAuth-stroom:

Eigenaar van de bron: u, de gebruiker met ergens gegevens
Client: de applicatie die toegang wil (bijvoorbeeld een agendaviewer van derden)
Authorisatieserver – de service die u authenticeert en tokens uitgeeft (bijvoorbeeld het OAuth-eindpunt van Google)
Resourceserver – de API die uw gegevens bevat (bijvoorbeeld Google Agenda API)

De autorisatiecodestroom

De standaard server-side stroom, vereenvoudigd:

U klikt op 'Verbind Google Agenda' in de client-app.
De client leidt uw browser om naar de autorisatieserver van Google met parameters: client_id, redirect_uri, scope (calendar.read), state (CSRF token).
U authenticeert zich bij Google als u nog niet bent ingelogd.
Google toont u een toestemmingsscherm: "CalendarViewer wil uw agenda lezen. Toestaan?"
U klikt op Toestaan. Google leidt uw browser terug naar de redirect_uri van de client met een eenmalige autorisatiecode.
De code aan de serverzijde van de client wisselt de autorisatiecode (plus het clientgeheim) uit voor een toegangstoken door het tokeneindpunt van Google rechtstreeks aan te roepen.
De client gebruikt het toegangstoken om namens u de Google Agenda-API aan te roepen.
Wanneer het toegangstoken verloopt (doorgaans een uur), gebruikt de client een vernieuwingstoken om een nieuwe te krijgen zonder dat u er last van heeft.

De cruciale beveiligingseigenschap: uw wachtwoord komt nooit in aanraking met de client-app. De client krijgt een scoped token dat u op elk gewenst moment kunt intrekken via het accountdashboard van Google.

OAuth 2.0 versus OAuth 2.1 versus OIDC

OAuth 2.0 is de standaard uit 2012 (RFC 6749). Sindsdien zijn er verschillende uitbreidings-RFC's en best practice-documenten toegevoegd.
OAuth 2.1 (in concept vanaf 2026) consolideert de huidige best practices in één enkele specificatie: verplichte PKCE, verwijderde Implicit Flow, etc.
OpenID Connect (OIDC) is een identiteitslaag bovenop OAuth 2.0. Alleen OAuth geeft een ondoorzichtig toegangstoken; OIDC voegt een ID-token (een JWT) toe dat de gebruiker verifieert. De meeste 'Aanmelden met...'-knoppen gebruiken OIDC, niet gewone OAuth.

De subsidietypen

OAuth 2.0 definieert verschillende stromen voor verschillende scenario's:

Authorisatiecode - de standaard server-side stroom die hierboven is beschreven. Met PKCE-extensie, ook gebruikt door mobiele en SPA-apps.
Implicit Flow (verouderd) - uitgegeven toegangstokens rechtstreeks via URL-fragment. Kwetsbaar voor tokenlekkage; vervangen door autorisatiecode + PKCE.
Resource-eigenaar Wachtwoordgegevens (zelden gebruikt) — de client verzamelt het wachtwoord van de gebruiker en wisselt dit in voor een token. Mag alleen worden gebruikt in oudere migratiescenario's.
Clientreferenties — voor machine-naar-machine waarbij er geen gebruiker is. De client authenticeert zichzelf en krijgt een token voor zijn eigen bronnen.
Apparaatcode - voor apparaten zonder browsers (tv's, IoT). Het apparaat toont een code; de gebruiker autoriseert vanaf een telefoon of laptop.
Refresh Token - wisselt een vernieuwingstoken met een lange levensduur uit voor een nieuw toegangstoken zonder gebruikersinteractie.

PKCE: de onmisbare extensie

PKCE (Proof Key for Code Exchange, uitgesproken als "pixie") voorkomt onderscheppingsaanvallen met autorisatiecodes. De client genereert een willekeurig geheim, hasht het en verzendt de hash in het autorisatieverzoek. Bij het uitwisselen van de code wordt het originele geheim verzonden. De autorisatieserver verifieert de hash-matches. Elke aanvaller die de code onderschept, kan deze niet uitwisselen zonder het oorspronkelijke geheim.

PKCE wordt nu als verplicht beschouwd voor alle OAuth-clients, zowel openbaar (browser, mobiel) als vertrouwelijk (serverzijde).

Scopes

Tokens worden uitgegeven met specifieke scopes: de acties die ze mogen uitvoeren. De typische scopes van Google zien eruit als https://www.googleapis.com/auth/calendar.readonly. De klant vraagt om scopes; de gebruiker ziet ze op het toestemmingsscherm en keurt deze goed of weigert. Het principe van de minste privileges: vraag alleen om de scopes die u daadwerkelijk nodig heeft.

Common OAuth-aanvallen

Open redirect. Met een verkeerd geconfigureerde parameter redirect_uri kan een aanvaller de autorisatiecode omleiden naar zijn eigen server.
State parameter omission. Zonder een statuswaarde die aan de gebruikerssessie is gekoppeld, OAuth-stromen zijn kwetsbaar voor CSRF: een aanvaller misleidt het slachtoffer zodat hij een OAuth-stroom voltooit die het account van de aanvaller koppelt aan de sessie van het slachtoffer.
Tokenlekkage in de browsergeschiedenis (de belangrijkste zwakte van de impliciete stroom).
Tokendiefstal via XSS. Als de client-app tokens opslaat localStorage en een XSS-kwetsbaarheid heeft, kunnen aanvallers deze stelen.
Phishing van het toestemmingsscherm. Een aanvaller registreert een kwaadaardige OAuth-client die om gevoelige scopes vraagt; de gebruiker, die op toestemmingsschermen op "Toestaan" moet klikken, verleent toegang zonder toezicht.

Wat te doen als gebruiker

Controleer regelmatig verbonden apps via de accountinstellingen van Google/Apple/Microsoft/Facebook/GitHub. Trek degene in die u niet gebruikt.
Lees de bereiken van het toestemmingsscherm voordat u toegang verleent. 'Je agenda beheren' verschilt van 'Je agenda bekijken'.
Wees sceptisch over OAuth-verzoeken van apps die je niet herkent, zelfs als ze verschijnen tijdens een bekende workflow.

Veelgestelde vragen

Is OAuth hetzelfde als authenticatie?: Nee. OAuth is autorisatie: het verleent de client toestemming om toegang te krijgen tot bronnen. OpenID Connect, gebouwd op OAuth, voegt authenticatie toe. "Aanmelden met Google" is OIDC; 'Verbind Google Agenda' kan afhankelijk zijn van de vraag of de app moet weten wie u bent of alleen toegang tot uw gegevens nodig heeft.
Moet ik OAuth gebruiken of wachtwoorden opslaan?: Gebruik OAuth waar mogelijk. Het opslaan van gebruikerswachtwoorden betekent dat u alle verantwoordelijkheid overneemt voor hashing, salt, reactie op inbreuken, wachtwoordherstel en 2FA. Door via OAuth te delegeren naar Google/Apple/Microsoft/GitHub wordt dat allemaal ontlast. Het nadeel is dat uw gebruikers accounts bij die providers nodig hebben.
Waarom kunnen OAuth-tokens worden ingetrokken, maar wachtwoorden niet?: Tokens verwijzen naar een vermelding in de database van de autorisatieserver. Als u de invoer intrekt, wordt het token onmiddellijk ongeldig. Wachtwoorden zijn kennis: u kunt het wachtwoord roteren en herauthenticatie afdwingen, maar het oude wachtwoord blijft geldig totdat u dat doet.
Wat is het verschil tussen OAuth 2.0 en OAuth 1.0?: OAuth 1.0 (2007) gebruikte bij elk verzoek cryptografische handtekeningen. OAuth 2.0 (2012) vertrouwt op TLS voor transportbeveiliging en gebruikt dragertokens. OAuth 2.0 is eenvoudiger te implementeren en wordt in vrijwel elke moderne API geleverd; OAuth 1.0 is feitelijk verouderd.
Zijn OAuth-tokens gevaarlijk als ze lekken?: Ja: iedereen met het token heeft de verleende toegang totdat deze verloopt of wordt ingetrokken. Oplossingen: korte levensduur van toegangstokens (normaal 1 uur), vernieuwingstokens veiliger opgeslagen, minimalisering van de scope, auditlogboekregistratie. Behandel toegangstokens tijdens hun geldigheidsduur met dezelfde zorg als wachtwoorden.