Authorization Code Flow

Denk aan de vier belangrijkste rollen in OAuth2:

• Resource Owner: de gebruiker die toegang verleent.
• Client: je applicatie die toegang vraagt.
• Authorization Server: verifieert de identiteit en geeft tokens uit.
• Resource Server: bevat de beveiligde gegevens.

In deze flow werken ze samen in een specifieke reeks van meerdere stappen.

Alles begint wanneer de Resource Owner (gebruiker) wil inloggen of toegang wil verlenen aan je Client-applicatie.

Je applicatie verwijst de browser van de gebruiker door naar het autorisatie-eindpunt van de Authorization Server en stuurt daarbij verschillende parameters mee:

• response_type=code (cruciaal!)
• client_id (de ID van je app)
• redirect_uri (waar de gebruiker naartoe moet worden teruggestuurd)
• scope (de aangevraagde machtigingen)
• state (voor de beveiliging, later uitgelegd)

Nadat de gebruiker is doorgestuurd naar de Authorization Server, ziet die een toestemmingsscherm.

Op dit scherm wordt gevraagd of de gebruiker ermee instemt om je Client-applicatie de aangevraagde machtigingen te geven (vastgelegd door scope).

De gebruiker kan vervolgens kiezen om het verzoek te Goedkeuren of te Weigeren.

Als de gebruiker goedkeurt, verwijst de Authorization Server de browser van de gebruiker terug naar de redirect_uri die je in stap 1 hebt opgegeven.

Deze URL bevat nu een eenmalig te gebruiken autorisatiecode en de parameter state die je hebt meegestuurd, bijvoorbeeld:

Deze code is kort geldig en geeft geen directe toegang tot resources.

Hier gebeurt het belangrijkste! De backend van je Client-applicatie ontvangt de autorisatiecode.

Vervolgens stuurt de backend een rechtstreeks HTTP POST-verzoek via een back-channel naar het token-eindpunt van de Authorization Server.

Dit verzoek bevat code, redirect_uri, client_id en, cruciaal, je client_secret om je applicatie te authenticeren.

De Authorization Server valideert het verzoek, vooral client_secret en code.

Als alles geldig is, geeft de server een toegangstoken en eventueel een vernieuwingstoken aan de backend van je Client-applicatie.

Je applicatie kan het toegangstoken nu gebruiken om namens de gebruiker verzoeken naar de Resource Server te sturen.

De parameter state is een belangrijke beveiligingsmaatregel tegen Cross-Site Request Forgery-aanvallen (CSRF).

Je Client moet voor elk autorisatieverzoek een unieke, cryptografisch willekeurige tekenreeks genereren en deze opnemen als de parameter state.

Wanneer de Authorization Server de gebruiker terugstuurt, bevat het verzoek dezelfde state. Je Client moet vervolgens controleren of de teruggestuurde state overeenkomt met de waarde die de client heeft verzonden, zodat je zeker weet dat de callback legitiem is.

De autorisatiecodeflow is het meest geschikt voor:

• Vertrouwelijke clients: vooral webserverapplicaties.
• Clients met een backend: waarbij client_secret veilig kan worden opgeslagen en gebruikt.
• Openbare clients met PKCE: (wordt in een latere les behandeld) mobiele apps en SPA's kunnen deze flow gebruiken met een uitbreiding genaamd PKCE voor betere beveiliging.

Dit is de meest robuuste keuze wanneer beveiliging van het grootste belang is.

Je beheerst nu de autorisatiecodeflow!

• Dit is de veiligste OAuth2-flow.
• Ideaal voor vertrouwelijke clients (server-side apps).
• Gebruikt een tijdelijke autorisatiecode om tokens te verkrijgen.
• De tokenuitwisseling vindt veilig plaats via een back-channel (van server naar server).
• De state-parameter beschermt tegen CSRF.

Deze flow vormt de basis voor veel veilige authenticatie- en autorisatiesystemen.