OAuth uitgelegd: rollen, de PKCE-flow en OAuth vs SAML
OAuth uitgelegd
Wat is OAuth? Rollen, PKCE-flow, OAuth vs SAML vs OIDC | We.Inc
OAuth 2.0 in gewone taal: vier rollen, de authorization code flow met PKCE stap voor stap, scopes, en hoe OAuth verschilt van OpenID Connect en SAML.
OAuth 2.0 is een standaard waarmee de ene app namens u kan handelen bij een andere dienst, zonder ooit uw wachtwoord te zien. U keurt een verzoek goed op de eigen inlogpagina van die dienst, en de app krijgt een access token dat beperkt is tot de scopes waarmee u akkoord ging. Het regelt autorisatie; OpenID Connect voegt daar inloggen aan toe.
OAuth 2.0 vs OpenID Connect vs SAML 2.0
OAuth 2.0
OpenID Connect
SAML 2.0
Beantwoordt
Waar mag deze app bij?
Wie is deze gebruiker?
Wie is deze gebruiker?
Belangrijkste artefact
Access token
ID-token (een JWT) plus access token
XML-assertion
Specificatie
RFC 6749 (IETF)
OpenID Connect Core 1.0
OASIS SAML 2.0
Partijen
Client, autorisatieserver, resourceserver
Relying party, OpenID-provider
Serviceprovider, identiteitsprovider
Typisch gebruik
API-toegang, "koppel uw account"
"Inloggen met"-knoppen, inloggen in mobiele apps en SPA's
Single sign-on op het werk
Vóór OAuth betekende het koppelen van twee diensten vaak dat u het wachtwoord van de ene in de andere typte. OAuth verving dat door kortlevende tokens met een smalle scope, die pas worden uitgegeven nadat u akkoord geeft. De generator hieronder maakt in uw browser een echte PKCE-verifier en -challenge en bouwt de autorisatie-URL, zodat u elke parameter ziet die de flow gebruikt.
De app maakt een willekeurige code_verifier, hasht die tot een code_challenge en stuurt u naar de autorisatieserver met die challenge, zijn client_id, de scopes en een state-waarde.
U logt in op de pagina van de autorisatieserver en keurt de scopes goed.
De server stuurt u terug naar de redirect_uri van de app met een kortlevende autorisatiecode en dezelfde state.
De app controleert state en post daarna de code en de oorspronkelijke code_verifier naar het token-endpoint.
De server hasht de verifier, vergelijkt die met de opgeslagen challenge en geeft een access token terug dat de app naar de API stuurt.
Gebruik de authorization code flow met PKCE voor single-page apps, mobiele apps en server-apps.
Stuur en controleer altijd state, wat de OAuth-specificatie aanraadt om cross-site request forgery te voorkomen.
Vraag om de smalste scopes die volstaan; mensen keuren kleine verzoeken sneller goed.
Registreer exacte redirect-URI's. Wildcards en open redirects zijn een klassieke manier waarop tokens worden gestolen.
Bewaar client secrets alleen op de server. Een browser- of mobiele app kan geen geheim bewaren.
Veelgestelde vragen
Is OAuth authenticatie of autorisatie?
Autorisatie. Een access token zegt wat een app mag doen, niet wie de gebruiker is, en API's vertellen u dat misschien niet eens. Hebt u de identiteit van de persoon nodig, gebruik dan OpenID Connect, dat een ondertekend ID-token teruggeeft met claims zoals sub, iss, aud en exp.
Wat is PKCE en heb ik het nodig?
PKCE (RFC 7636) koppelt de autorisatiecode aan de app die de flow startte. De app stuurt eerst een hash van een willekeurig geheim en later het geheim zelf, waardoor een gestolen code nutteloos is. Gebruik S256, dat servers moeten ondersteunen, in plaats van plain.
Wat is het verschil tussen OAuth en SAML?
SAML is een oudere, op XML gebaseerde standaard waarbij een identiteitsprovider een ondertekende assertion over de gebruiker naar een serviceprovider stuurt, vooral voor zakelijke single sign-on in browsers. OAuth geeft tokens uit voor API-toegang en werkt goed voor mobiele apps en API's. OpenID Connect is binnen de OAuth-wereld het dichtste equivalent van inloggen met SAML.
Wat zijn scopes?
Scopes zijn de rechten waar een app om vraagt, geschreven als een door spaties gescheiden lijst hoofdlettergevoelige strings die de autorisatieserver definieert, bijvoorbeeld openid email of repo read:user. Het toestemmingsscherm toont ze, en het token dekt alleen wat is goedgekeurd.
Moet ik de implicit flow nog gebruiken?
Niet voor nieuw werk. Die gaf tokens terug in het URL-fragment, waar ze via de geschiedenis en logs kunnen uitlekken. De authorization code flow met PKCE geeft browser-apps hetzelfde gemak zonder dat risico.
De vier rollen
RFC 6749 noemt vier partijen. De resource owner bent u. De client is de app die om toegang vraagt. De autorisatieserver controleert wie u bent en geeft tokens uit. De resourceserver host de API die die tokens accepteert. Vaak beheert één bedrijf beide servers, maar het zijn aparte taken.
Waarom de code-uitwisseling bestaat
De redirect terug naar de app gaat via de browser, en dat is een lekke plek voor alles wat waardevol is. Daarom bevat de redirect alleen een eenmalige code, die volgens de aanbeveling van de specificatie binnen 10 minuten verloopt. Het echte token wordt opgehaald met een directe aanroep naar het token-endpoint.
PKCE dicht het resterende gat. Zelfs als malware of een loggende proxy de code onderschept, kan die hem niet inwisselen zonder de verifier, die de app nooit heeft verlaten.
Waar OpenID Connect past
OpenID Connect is een dunne laag bovenop OAuth. Voeg openid toe aan de scopes, wat de OIDC-specificatie verplicht stelt, en de tokenrespons bevat ook een ID-token: een ondertekende JWT die de gebruiker beschrijft. Een nonce die in het verzoek wordt meegestuurd en in het ID-token terugkomt, beschermt tegen replay.
access_token, token_type, expires_in, optioneel refresh_token (en id_token met OIDC)
6. API-aanroep
App naar resourceserver
Authorization: Bearer <access_token>
PKCE in code
Een verifier en S256-challenge maken in de browser
32 willekeurige bytes, gecodeerd als base64url, geven een verifier van 43 tekens, de kortste lengte die RFC 7636 toestaat.
De code inwisselen voor tokens
Draait na de redirect. Vergelijk eerst state en stuur daarna de opgeslagen verifier mee met de code.
Generator voor PKCE en autorisatie-URL
Maakt met de crypto van uw browser een verse code_verifier en de bijbehorende S256-code_challenge, en stelt daarna een autorisatie-URL samen uit uw instellingen. Er wordt niets verstuurd; het endpoint hieronder is een placeholder die u vervangt.
Autorisatie-endpoint
Scopes (door spaties gescheiden)
Nieuwe verifier
code_verifier ({n} tekens, geheimhouden tot stap 4)