Wat zijn bearer tokens?

Achter bijna elke moderne app-login of API-aanvraag schuilt een stille krachtpatser: de bearer token. Je merkt het misschien niet, maar hij is er telkens als je diensten koppelt, inlogt of gegevens ophaalt uit de cloud.

Deze gids legt uit wat bearer tokens doen, waarom ze belangrijk zijn en hoe je er veilig mee omgaat.

Wat is een bearer token?#

Een bearer token is een stukje data, meestal een reeks tekens, dat bewijst dat de houder toegang mag krijgen tot een resource. Het belangrijkste is dat wie de token ook draagt, hem kan gebruiken zonder extra bewijs te hoeven leveren.

Denk aan een instapkaart van een luchtvaartmaatschappij. Zodra je die in handen hebt, kun je door de beveiliging en aan boord van het vliegtuig. Niemand vraagt je om je ID opnieuw te tonen als de instapkaart geldig is. Op dezelfde manier laat een bearer token je applicatie "aan boord van de API" gaan zonder telkens opnieuw je identiteit te hoeven controleren.

Bijvoorbeeld: als je bent ingelogd bij Spotify op je telefoon, hoef je niet telkens je wachtwoord in te voeren als je een nummer afspeelt. In plaats daarvan slaat de app een bearer token op die aan Spotify’s servers vertelt: “dit verzoek komt van een geautoriseerde gebruiker.”

Hoe werken bearer tokens in de praktijk?#

De stroom van bearer tokens is op te splitsen in een paar stappen:

1. Gebruiker logt in

   Stel, je logt in bij een bankapp met je gebruikersnaam en wachtwoord.

2. Identity provider geeft een token uit

   Na verificatie stuurt de authenticatieserver een bearer token terug. Dit kan er zo uitzien:

3. Client gebruikt het token

   Elke keer dat je op “Saldo controleren” of “Geld overmaken” tikt, voegt de app het token toe aan het HTTP-verzoek:

4. API valideert het

   De server controleert of het token nog geldig is, niet verlopen, en de juiste rechten bevat (zoals read:balance of write:transfer).

5. Toegang verleend

   Als alle controles slagen, reageert de server met de gevraagde informatie.

Dit model wordt veel gebruikt bij diensten als de GitHub APIs, waar ontwikkelaars zich authenticeren met een bearer token in plaats van telkens hun inloggegevens in te voeren.

Waarom zijn bearer tokens populair geworden?#

Bearer tokens zijn populair geworden omdat ze veelvoorkomende problemen van webbeveiliging oplossen. In tegenstelling tot servergebaseerde sessies hoeft er geen data opgeslagen te worden voor elke ingelogde gebruiker. In plaats daarvan bevat het token zelf voldoende informatie zodat de server de aanvraag kan valideren.

Bijvoorbeeld, in een microservices-architectuur, waar tientallen services met elkaar communiceren, zou centrale sessieopslag complex en inefficiënt zijn. Met bearer tokens kan elke service aanvragen onafhankelijk valideren en blijft het systeem lichtgewicht en schaalbaar.

Een concreet voorbeeld: Slack’s APIs vertrouwen sterk op bearer tokens. Als je een Slack bot bouwt, krijg je een token waarmee je bot Slack’s endpoints kan aanroepen zonder voor elke gebruiker een aparte sessie te hoeven onderhouden.

Wat zit er in een bearer token?#

Veel bearer tokens zijn geïmplementeerd als JWTs (JSON Web Tokens). Dit zijn gecodeerde tokens die informatie bevatten over de gebruiker en diens rechten.

Laten we een voorbeeld-JWT decoderen:

Dit betekent het volgende:

• sub: Het subject, oftewel het unieke ID van de gebruiker.
• name: De naam van de gebruiker.
• iat: Aanmaak-tijd (issued at timestamp).
• exp: Vervaltijd (wanneer het token ongeldig wordt).
• scope: De machtigingen, in dit geval mag de app berichten lezen én schrijven.

Stel dat Jane’s token alleen de scope read:messages had, dan zou de app alleen haar berichten kunnen ophalen maar geen nieuwe namens haar versturen.

Bearer tokens vs. access tokens: Wat is het verschil?#

Het is makkelijk om bearer tokens en access tokens door elkaar te halen, omdat de termen vaak samen worden gebruikt. Ze zijn verwant, maar niet identiek.

Access token: Het “Toestemmingsbriefje”#

Een access token is een bewijsstuk dat de autorisatie van een gebruiker vertegenwoordigt om toegang te krijgen tot een resource. Het bevat informatie zoals:

• Wie de gebruiker is (hun ID)
• Wat ze mogen doen (scopes/machtigingen)
• Wanneer het token vervalt

Zie het als een toestemmingsbriefje getekend door de schooldirecteur. Het vertelt de docent (de API) dat je mee mag op het schoolreisje (de resource mag betreden).

Bijvoorbeeld, wanneer je inlogt bij een cloudopslagdienst, geeft het systeem een access token uit met de scope read:files. Daarmee weet de opslag-API: “Deze gebruiker mag bestanden lezen, maar niet verwijderen.”

Bearer token: Het “Afleverformaat”#

Een bearer token is een type access token. Het woord bearer beschrijft hoe het token wordt gebruikt: wie het token presenteert mag ermee resources benaderen, zonder verdere identiteitscontrole.

Met andere woorden:

• Alle bearer tokens zijn access tokens.
• Maar niet alle access tokens hoeven bearer tokens te zijn.

Er zijn ook andere tokentypes, zoals holder-of-key tokens, waarbij de client naast het token moet bewijzen dat die een cryptografische sleutel bezit. Bearer tokens slaan die stap over, waardoor ze eenvoudiger maar ook riskanter zijn als ze gestolen worden.

Voorbeeld in de praktijk#

• Access token (algemeen): Kan een getekend stuk data zijn, waarbij de client soms moet bewijzen ook een privésleutel te bezitten.
• Bearer token (specifiek): De meeste OAuth 2.0 implementaties geven tegenwoordig access tokens uit in bearer-formaat. Bijvoorbeeld: Google OAuth retourneert een access token dat je gebruikt in de Authorization: Bearer <token> header.

Dit betekent dat als je “access token” ziet in OAuth-tutorials het vrijwel altijd een bearer token is, tenzij anders vermeld.

Andere tokentypes vergeleken#

Om het plaatje compleet te maken, vergelijken we bearer tokens met enkele andere veelvoorkomende tokentypes:

• Refresh token: Gebruikt om een nieuw access token te verkrijgen als het oude is verlopen. Refresh tokens zijn meestal geen bearer tokens, omdat ze veilig worden uitgewisseld met de authorization server en niet direct naar APIs worden gestuurd.
• ID token: Wordt gebruikt voor authenticatie, niet voor autorisatie. Het bevat identiteitsgegevens van de gebruiker (zoals e-mail, naam of gebruikers-ID). Afhankelijk van het systeem kan een ID token óók een bearer token zijn, maar het doel ervan verschilt van een access token.
• API key: Een eenvoudigere vorm van bewijsstuk dat de aanroepende applicatie identificeert. In veel gevallen werken API keys als bearer tokens, omdat wie de sleutel heeft, de API kan aanroepen.

Bearer tokens en access tokens zijn geen tegenpolen — ze overlappen:

• De meeste access tokens zijn bearer tokens.
• Een bearer token beschrijft hoe een token wordt gebruikt (tonen om toegang te krijgen).
• In dagelijks gebruik worden de termen “access token” en “bearer token” vaak door elkaar gebruikt, hoewel ze technisch op verschillende aspecten wijzen.

Hoe valideer je een JWT access token (Bearer token)#

Het valideren van een bearer token is wat jouw API beschermt tegen ongeoorloofde toegang. Als je tokens JWTs zijn, gebeurt validatie lokaal en snel. De API kan het token zelf controleren, zonder telkens de uitgever te hoeven raadplegen.

Het basisidee#

1. Parseer het token.
2. Verifieer de handtekening met de publieke sleutel van de uitgever.
3. Controleer standaard-claims zoals issuer, audience, expiry, not-before.
4. Dwing je app-regels af zoals scopes, rollen en tokentype.
5. Raadpleeg eventueel revocatielijsten of sessiestatus bij risicovolle acties.

Validatielijst (JWT)#

Gebruik dit als runbook bij het opzetten van een API gateway of middleware.

• Handtekening

  Controleer de handtekening met het algoritme in de header (bijvoorbeeld RS256). Haal het JWKS-endpoint van de uitgever op, kies de sleutel die bij de kid hoort, en cache deze.

• Issuer (iss)

  Match de iss van het token exact aan jouw vertrouwde issuer-URL, inclusief het juiste schema.

• Audience (aud)

  Zorg ervoor dat het token bedoeld was voor jouw API. Vergelijk dit met jouw API-identificatie zoals https://api.example.com of een logische audience string.

• Vervaldatum (exp) en Not-Before (nbf)

  Wijs verlopen tokens af. Respecteer nbf zodat een token niet gebruikt kan worden vóór de aanvangstijd. Sta een kleine tijdsverschil toe, meestal 30 tot 60 seconden.

• Issued-At (iat)

  Handig voor debugging en voor het afwijzen van erg oude tokens in strikte setups.

• Tokentype

  Bevestig dat het een access token is. Sommige aanbieders voegen typ: "at+jwt" of iets vergelijkbaars toe. Accepteer geen ID tokens voor API-toegang.

• Scopes / machtigingen

  Lees de scope of provider-specifieke claims (bijvoorbeeld permissions, rollen). Dwing least-privilege af op elke endpoint.

• Subject (sub)

  De stabiele gebruikers- of client-ID. Gebruik dit voor het koppelen van resources of voor auditing.

• Replay en revocatie (optioneel, maar verstandig)

  Controleer bij gevoelige endpoints een korte denylist van jti’s, of valideer een actieve sessie. Dit helpt na uitloggen of bij vermoede compromittering.

Beveiligingsrisico’s van bearer tokens#

Omdat bearer tokens werken als “degene die het token heeft kan deze gebruiken”, moeten ze behandeld worden als huissleutels. Als iemand je sleutel steelt, kan hij je deur openen tot je het slot vervangt.

Veelvoorkomende risico’s zijn:

• Token diefstal – Als een hacker toegang krijgt tot browser localStorage waar een token wordt opgeslagen, kan hij de gebruiker imiteren. Bijvoorbeeld: in 2018 bleek dat sommige browser extensies tokens uit localStorage stalen en verkochten.
• Replay aanvallen – Een aanvaller die een token onderschept, kan het hergebruiken tot het verlopen is. Zonder HTTPS is dit verrassend makkelijk.
• Langlevende tokens – Als een token weken of maanden geldig blijft, vergroot dat het risico voor aanvallers.

In het echt zijn datalekken ontstaan doordat ontwikkelaars per ongeluk bearer tokens committen in openbare GitHub repositories. Aanvallers kunnen tokens opsporen en onmiddellijk misbruiken om ongeoorloofde toegang te krijgen.

Best practices voor het gebruik van bearer tokens#

Om bearer tokens veilig te gebruiken, is het belangrijk best practices te volgen. Laten we ze samen doorlopen met voorbeelden:

1. Gebruik altijd HTTPS

   Stel je voor dat je een token verstuurt via HTTP op een openbaar café-wifi netwerk. Iedereen die meeluistert kan het token kopiëren en als jou inloggen.

2. Gebruik kortlevende access tokens

   De meeste platforms geven tokens uit die binnen een uur vervallen. Google’s OAuth tokens zijn bijvoorbeeld meestal 1 uur geldig voordat ze ververst moeten worden.

3. Gebruik refresh tokens met zorg

   Een refresh token kan nieuwe access tokens aanvragen zonder dat de gebruiker opnieuw hoeft in te loggen. Maar hij moet veilig worden opgeslagen (bijvoorbeeld in een versleutelde database op de server) en niet client-side.

4. Ken tokens zo minimaal mogelijke rechten toe

   Als jouw app alleen iemands agenda hoeft te lezen, vraag dan geen write:calendar toegang aan. Dat minimaliseert schade als een token onverhoopt uitlekt.

5. Revokeer tokens indien nodig

   Veel SaaS apps laten gebruikers actieve sessies zien en intrekken. GitHub bijvoorbeeld laat je persoonlijke access tokens op elk moment intrekken.

6. Monitor gebruik

   Het loggen van tokengebruik kan verdachte activiteiten aan het licht brengen. Bijvoorbeeld: als hetzelfde token plotseling wordt gebruikt vanuit Londen én New York binnen enkele minuten, is dat een alarmsignaal.

Bearer tokens vs. andere authenticatiemethoden#

Het is nuttig bearer tokens te vergelijken met andere populaire benaderingen:

• Cookies & Sessies

  Traditionele websites maken gebruik van serveropgeslagen sessies, geïdentificeerd met een cookie. Dit werkt goed voor browser-apps maar is minder efficiënt voor APIs of mobiele apps. Bijvoorbeeld: Facebook op desktop gebruikt vooral cookies, de mobiele API’s gebruiken tokens.

• API sleutels

  Een API sleutel is een statische string die een applicatie, niet de gebruiker, authenticeert. Een weer-app gebruikt bijvoorbeeld een API sleutel om data op te halen, maar deze sleutel vertelt de server niet welke gebruiker het verzoek doet. Bearer tokens kunnen gebruikersspecifieke gegevens bevatten en zijn daarmee veelzijdiger.

• Mutual TLS (mTLS)

  Sommige zeer veilige systemen vereisen certificaten aan beide kanten. Hoewel dit veiliger is, is het lastiger op grote schaal toe te passen. Voor de meeste SaaS-platforms bieden bearer tokens de juiste balans tussen gebruiksgemak en beveiliging.

Belangrijkste punten#

• Bearer tokens zijn simpel maar krachtig: wie het token heeft, kan bij de resource.
• Ze worden veel gebruikt in OAuth 2.0- en OIDC-flows, vooral voor APIs en mobiele apps.
• Beveiliging hangt af van hoe je ze beheert: korte levensduur, scopes, HTTPS en revocatie zijn belangrijk.
• Ze zijn niet altijd de beste keuze maar vormen in de meeste SaaS- en API-contexten de juiste balans tussen veiligheid en gemak.