De OAuth 2.0-autorisatiecodeflow

De vier rollen, de redirect-en-ruil-dans, en waarom de code op het achterkanaal wordt geruild voor een token.

Waar de flow voor is

2.0 (RFC 6749) laat een applicatie namens een gebruiker handelen zonder ooit het wachtwoord van de gebruiker te zien. "Inloggen met Google" is het alledaagse voorbeeld: de app krijgt toestemming om iets te benaderen, maar Google, niet de app, behandelt de inloggegevens. De autorisatiecodeflow is de meest gangbare en meest veilige manier om dit te regelen, en het is de flow die beschermt.

De vier rollen

De resource-eigenaar (resource owner) is de gebruiker die de data bezit en de toegang verleent.
De client is de applicatie die de toegang aanvraagt.
De autorisatieserver (authorization server) authenticeert de gebruiker en geeft tokens uit (Google, een identiteitsprovider, je eigen auth-dienst).
De resourceserver (resource server) is de API die de beschermde data houdt en het token accepteert.

De dans, stap voor stap

Doorverwijzen om te autoriseren. De client zendt de browser van de gebruiker naar het autorisatie-endpoint van de autorisatieserver, met zijn client_id, een redirect_uri, de gewenste scope, een willekeurige state-waarde en (met PKCE) een code-challenge. De client behandelt het wachtwoord nooit.
Authenticeren en toestemmen. De autorisatieserver logt de gebruiker in en vraagt hem de gevraagde scopes goed te keuren.
Terugverwijzen met een code. De server verwijst de browser terug naar de redirect_uri van de client met een kortlevende autorisatiecode en de oorspronkelijke state. De client controleert dat de state overeenkomt, wat verdedigt tegen cross-site request forgery bij de callback.
De code ruilen voor tokens. Nu op het achterkanaal (een directe server-naar-server-oproep, niet de browser), zendt de client de code naar het token-endpoint samen met zijn inloggegevens (een clientgeheim, of de PKCE-codeverifier) en ontvangt een toegangstoken, vaak een verniewingstoken, en voor OpenID Connect een ID-token.
De API aanroepen. De client legt het toegangstoken voor aan de resourceserver, die het valideert en de data retourneert.

Waarom een code, en niet het token rechtstreeks?

De omweg via een autorisatiecode bestaat zodat het token nooit door de adresbalk of geschiedenis van de browser reist, waar het zou kunnen lekken. De code die daar wel reist is op zichzelf nutteloos: hem inwisselen vereist de achterkanaaloproep met het clientgeheim of de PKCE-verifier. Die scheiding, een wegwerpcode op het voorkanaal en het echte token op het achterkanaal, is de kernbeveiligingseigenschap van de flow.

Dit is ook precies het gat dat PKCE vult voor clients die geen geheim kunnen bewaren (single-page- en mobiele apps): het bindt de code aan een eenmalige verifier zodat een onderschepte code toch niet kan worden geruild. De tokens die de flow retourneert zijn heel vaak 's.

De PKCE-tool genereert en controleert de verifier en challenge waarop deze flow steunt, en de JWT-tool decodeert de tokens die hij retourneert, beide lokaal in je browser.