Leer wat bearer tokens zijn, hoe ze werken in OAuth 2.0 en JWT, het verschil met toegangstokens en best practices.
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.
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.”
De stroom van bearer tokens is op te splitsen in een paar stappen:
Gebruiker logt in
Stel, je logt in bij een bankapp met je gebruikersnaam en wachtwoord.
Identity provider geeft een token uit
Na verificatie stuurt de authenticatieserver een bearer token terug. Dit kan er zo uitzien:
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:
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).
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.
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.
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.
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.
Een access token is een bewijsstuk dat de autorisatie van een gebruiker vertegenwoordigt om toegang te krijgen tot een resource. Het bevat informatie zoals:
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.”
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:
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.
<token> header.Dit betekent dat als je “access token” ziet in OAuth-tutorials het vrijwel altijd een bearer token is, tenzij anders vermeld.
Om het plaatje compleet te maken, vergelijken we bearer tokens met enkele andere veelvoorkomende tokentypes:
Bearer tokens en access tokens zijn geen tegenpolen — ze overlappen:
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.
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.
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:
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.
Om bearer tokens veilig te gebruiken, is het belangrijk best practices te volgen. Laten we ze samen doorlopen met voorbeelden:
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.
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.
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.
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.
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.
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.
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.