JWT vs OAuth: Belangrijkste verschillen, hoe ze samenwerken en best practices

Als je nieuw bent met authenticatie en een app bouwt die logins, betalingen of gebruikersgegevens afhandelt, ben je waarschijnlijk de termen JWT en OAuth tegengekomen. Ze klinken misschien als complexe, "alleen-backend" onderwerpen, maar ze zijn niet alleen voor security engineers.

Met API's, integraties van derden en opkomende technologieën zoals AI, MCP en agentgebaseerde systemen, spelen deze twee een directe rol in de bruikbaarheid, veiligheid en groei van je product. De basis begrijpen betekent dat je kunt:

• Functies ontwerpen die vanaf het begin veilig zijn
• Effectief communiceren met je engineeringteam
• Betere productbeslissingen nemen over authenticatie en gebruikersflows
• Kostbare beveiligingsfouten voorkomen die het vertrouwen van gebruikers schaden

Bijvoorbeeld, in de laatste MCP specificatie, is het autorisatiesysteem gebouwd op bewezen standaarden:

• OAuth 2.1 IETF Draft (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Authorization Server Metadata (RFC8414)
• OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
• OAuth 2.0 Protected Resource Metadata (RFC9728)

Waarom dit belangrijk is#

Zelfs als je nooit backend-code schrijft:

• Ontwikkelaars leren hoe ze API's moeten beveiligen, sessies beheren en integreren met diensten van derden.
• Productmanagers krijgen de juiste terminologie om login flows, integraties en compliance te bespreken met teams en partners.
• Oprichters en vroege teams voorkomen dat ze kwetsbare inlogsysteem bouwen die stuk gaan bij integraties of je kwetsbaar maken voor inbreuken.

JWT vs OAuth: De twee kernconcepten#

JWT (JSON Web Token) en OAuth (Open Authorization) worden vaak samen gebruikt, maar dienen een ander doel.

Zie het als volgt:

• OAuth is hoe je iemand de sleutel geeft, maar alleen tot de kamers waar ze in mogen.
• JWT is het identiteitsbewijs dat ze meenemen, het bewijs van wie ze zijn en wat ze mogen doen.

In de volgende sectie zetten we ze naast elkaar zodat je duidelijk het verschil en hun samenwerking ziet.

Wat is OAuth 2.0?#

OAuth 2.0 is een breed geadopteerd autorisatiekader dat een applicatie (de client) in staat stelt om met beperkte machtigingen toegang te krijgen tot de bronnen van een gebruiker, zonder dat de inloggegevens (zoals wachtwoorden) gedeeld hoeven te worden.

Kernrollen in OAuth#

• Client: De applicatie die toegang aanvraagt.
• Resource eigenaar: Meestal de gebruiker, die toestemming geeft.
• Autorisatieserver: Geeft toegangstokens uit na autorisatie.
• Bronnenserver: Host de beschermde bronnen en valideert tokens.

Veelvoorkomende OAuth grant types (Flows)#

• Authorization Code Grant: Meest veilig en aanbevolen, vooral met PKCE voor browser, SPA en mobiele apps.
• Implicit Grant: Wordt nu afgeraden in OAuth 2.1 om veiligheidsredenen.
• Resource Owner Password Credentials (ROPC): Wisselt direct gebruikersnaam en wachtwoord uit voor tokens; minder veilig.
• Client Credentials Grant: Voor server-tot-server of machine-to-machine communicatie.
• Device Flow: Voor apparaten zonder toetsenbord (bijv. smart-tv's), waar gebruikers via een tweede apparaat autoriseren.

Wat is JWT (JSON Web Token)?#

Een JWT is een open standaard (RFC 7519) voor het veilig verzenden van claims tussen twee partijen op een compacte, URL-veilige manier.

Structuur van een JWT#

Een JWT bestaat uit drie base64url-gecodeerde delen, gescheiden door punten (.):

1. Header: Geeft het algoritme aan (bijv. HS256, RS256) en het type token (JWT).
2. Payload: Bevat claims, zoals:
   • iss (issuer)
   • sub (subject, bijv. gebruikers-ID)
   • aud (audience)
   • exp (vervaldatum)
   • Aangepaste claims indien nodig
3. Signature: Verifieert dat het token niet is gewijzigd.

Voorbeeld:

Een JWT-voorbeeld#

Hier is een voorbeeld van een typische JWT in gecodeerde vorm, samen met de gedecodeerde structuur zodat je ziet waar elk deel voor staat.

Gecodeerde JWT (Base64URL)

Dit bestaat uit drie delen gescheiden door punten: header.payload.signature

Gedecodeerde structuur

• Header

• Payload

De payload bevat claims

• Signature

De signature zorgt ervoor dat het token niet is aangepast.

Belangrijkste kenmerken#

• Self-contained: Alle benodigde informatie zit in het token.
• Stateless: Geen server-side sessieopslag nodig.
• Ondertekend: (En optioneel versleuteld) om authenticiteit te waarborgen.

JWT vs OAuth: Kernverschillen#

Kort samengevat:

• JWT is de container: als een paspoort met identiteitsgegevens.
• OAuth is het systeem: zoals grenscontrole, die bepaalt wie het paspoort krijgt en wat ermee mag.

Wanneer JWT alleen gebruiken#

Gebruik JWT op zichzelf als:

• Authenticatie binnen één systeem waarbij je app tokens uitgeeft en verifieert zónder externe identiteitsprovider.
• Stateless sessiebeheer om gebruikersidentiteit te valideren zonder sessiegegevens op de server op te slaan.
• Eenvoudige API-authenticatie voor interne API's die alleen basisrechten hoeven te controleren zonder ingewikkelde toestemmingsflows.
• Prestatiegerichte validatie zodat bronnenservers tokens lokaal kunnen valideren zonder een auth-server te raadplegen.

Voorbeeld:

Een single-page app en backend-API waar je eigenaar van bent. De API geeft een JWT uit met sub (gebruikers-ID), rol en exp (verloop) claims.

Wanneer OAuth alleen gebruiken#

Gebruik OAuth zonder JWT als:

• Je geen self-contained tokens hoeft te gebruiken en ondoorzichtige tokens die moeten worden opgezocht acceptabel zijn.
• Je wil dat de bronnenserver altijd navraagt bij de autorisatieserver voordat toegang wordt verleend.
• Je in een legacy- of gereguleerde omgeving werkt waar JWT niet geschikt is.
• Het doel gedelegeerde autorisatie is om beperkt toegang veilig te kunnen geven aan applicaties van derden.

Voorbeeld:

Een API die ondoorzichtige toegangstokens uitgeeft en elk verzoek valideert door de autorisatieserver te bevragen.

Wanneer beide JWT en OAuth gebruiken#

Gebruik ze samen als:

• Je meerdere services of API's hebt en OAuth gebruikt voor het veilige flow en JWT voor verifieerbare tokens tussen services.
• Je externe login aanbiedt zoals “Inloggen met Google”, waarbij OAuth toestemming regelt en JWT het toegangstoken of ID-token bevat.
• Je een microservices-architectuur draait waar elke service JWT's lokaal valideert.
• Je schaalbaarheid nodig hebt met het delegatiemodel van OAuth en de stateless validatie van JWT.

Voorbeeld:

Je app laat gebruikers inloggen met Google. OAuth regelt het autorisatieproces, Google geeft een JWT access token uit en je API's valideren deze lokaal voordat ze data teruggeven.

Hoe JWT en OAuth samenwerken#

In moderne authenticatie-/autorisatieoplossingen:

1. OAuth regelt het proces om toegang te verlenen.
2. De autorisatieserver geeft een toegangstoken uit: vaak een JWT.
3. De JWT wordt meegestuurd met API-verzoeken om identiteit en rechten te bewijzen.

Speciale tokens in OAuth#

• ID token: Gebruikt in OpenID Connect als bewijs van de gebruikersidentiteit; altijd een JWT.
• Access token: Kan een JWT of een ondoorzichtig token zijn.

Best practices van JWTs en OAuth#

• Gebruik HTTPS om tokens onderweg te beschermen.
• Stel korte verliestijden in voor JWTs; gebruik refresh tokens voor langere sessies.
  • https://auth.wiki/offline-access.
• Valideer de handtekening vóór je claims vertrouwt.
• Controleer de aud claim om te waarborgen dat het token voor jouw app bedoeld is.
• Sla tokens niet op in localStorage als XSS een risico is; geef de voorkeur aan veilige cookies.

Tot slot#

• OAuth 2.0 definieert hoe je tokens verkrijgt en gebruikt.
• JWT definieert hoe het token eruitziet en informatie overbrengt.
• Ze zijn complementair, niet uitwisselbaar.

De meeste moderne API's gebruiken OAuth voor autorisatiefows en JWT als tokenrepresentatie. Beide begrijpen helpt je om veilige, schaalbare authenticatiesystemen te ontwerpen.