Bearer-token: de digitale toegangspas die websites en AI-tools gebruiken
Stel je voor: je koopt een kaartje voor een festival en krijgt bij de ingang een polsbandje om. De rest van de dag hoeft niemand meer je paspoort te controleren. Elke bewaker die het polsbandje ziet, laat je door — niet omdat ze weten wie je bent, maar simpelweg omdat je het bandje draagt. Een bearer-token werkt op internet precies zo. Het is een stukje digitale tekst dat bewijst dat je ergens toegang toe hebt, zonder dat de ontvanger opnieuw je wachtwoord of identiteit hoeft te checken.
De term komt uit het Engels: bearer betekent "drager" of "houder". Een bearer-token is dus letterlijk een toegangsbewijs voor wie het "draagt" — wie het token bezit, mag het gebruiken, ongeacht wie diegene daadwerkelijk is. Dat maakt het razendsnel en simpel voor computers om met elkaar te communiceren, bijvoorbeeld wanneer een app namens jou gegevens ophaalt bij Google, of wanneer een AI-assistent een extern programma aanroept. Maar diezelfde eigenschap is meteen ook de achilleshiel: net als bij contant geld geldt bij een bearer-token "wie het heeft, mag het uitgeven".
Wat is het precies?
Een bearer-token duikt op in de wereld van API's (Application Programming Interfaces): de "loketten" waarlangs computerprogramma's met elkaar praten, bijvoorbeeld wanneer een weer-app gegevens opvraagt bij een weerdienst. Om te voorkomen dat iedereen zomaar bij die loketten naar binnen kan, wordt toegang beveiligd met een token.
Het proces verloopt meestal in een paar stappen. Eerst logt een gebruiker of programma ergens in met een wachtwoord, sleutel of ander bewijs van identiteit. De server die de identiteit controleert, geeft daarna een token uit: een lange, willekeurig ogende tekenreeks. Vanaf dat moment hoeft de gebruiker niet telkens opnieuw het wachtwoord te tonen. Bij elk volgend verzoek stuurt de client (de app, browser of het programma) het token gewoon mee, in een onderdeel van het HTTP-verzoek dat de Authorization-header heet. Dat ziet er in de praktijk uit als de tekst "Authorization: Bearer <token>", vandaar de naam.
Een veelgebruikt formaat voor zo'n token is de JWT (JSON Web Token, uitgesproken als "jot"). Een JWT bestaat uit drie met punten gescheiden delen: informatie over het type token, de eigenlijke gegevens (bijvoorbeeld wie de gebruiker is en tot wanneer het token geldig is) en een digitale handtekening waarmee de ontvanger kan controleren dat het token echt is en niet is aangepast. Niet elk bearer-token is een JWT — het kan ook een willekeurige code zijn die de server in een database opzoekt — maar JWT is wel de bekendste variant.
Bearer-tokens verschillen van de klassieke cookie die websites gebruiken om je ingelogd te houden. Een cookie wordt automatisch door de browser meegestuurd zodra je een website bezoekt, en is sterk verbonden met dat ene browservenster. Een bearer-token moet de client zelf actief toevoegen aan elk verzoek, wat het geschikter maakt voor apps, mobiele toepassingen en communicatie tussen servers onderling, waar geen browser aan te pas komt.
Het kernpunt — en meteen het risico — zit in het woordje "bearer". De server die het token ontvangt, vraagt zich niet af of jij wel echt bent wie je zegt te zijn; hij controleert alleen of het token geldig en niet verlopen is. Komt een token in verkeerde handen, bijvoorbeeld doordat het onderschept wordt of per ongeluk in publiek toegankelijke code belandt, dan kan de dief zich voordoen als de rechtmatige gebruiker totdat het token verloopt of wordt ingetrokken. Daarom wordt zo'n token altijd verstuurd via TLS/HTTPS, de versleutelde verbinding die voorkomt dat iemand onderweg meekijkt.
Wat wil men ermee bereiken?
Een belangrijke drijfveer is stateless authenticatie: de server hoeft geen lijst bij te houden van wie er allemaal ingelogd is. Alle benodigde informatie zit al in het token zelf. Dat is vooral handig in moderne cloud-systemen, waar een verzoek door tientallen verschillende servers kan worden afgehandeld — elke server kan het token zelfstandig controleren, zonder ruggespraak met een centrale sessie-database. Dat maakt grootschalige, snel schaalbare systemen eenvoudiger te bouwen.
Een tweede doel is gedelegeerde toegang, het kernidee achter het standaardprotocol OAuth. Dankzij OAuth kun je een app toestemming geven om, bijvoorbeeld, jouw Google Agenda te lezen zonder dat je die app ooit je Google-wachtwoord geeft. Google geeft in plaats daarvan een beperkt geldig bearer-token uit, met precies de rechten die nodig zijn en niet meer dan dat.
Daarnaast zorgt standaardisatie ervoor dat verschillende systemen elkaar begrijpen: doordat vrijwel iedereen dezelfde "Authorization: Bearer"-header gebruikt, kunnen ontwikkelaars overal ter wereld met dezelfde bouwstenen werken. Tot slot wordt het mechanisme steeds belangrijker voor machine-tot-machine-communicatie en voor AI-agents: software die zelfstandig taken uitvoert en daarbij namens een gebruiker toegang nodig heeft tot allerlei diensten, gebruikt vrijwel altijd bearer-tokens om zich bij die diensten te legitimeren.
Voorbeelden uit de praktijk
Het gebruik van bearer-tokens werd in 2012 formeel vastgelegd door de internetstandaardisatie-organisatie IETF in document RFC 6750, onderdeel van de bredere OAuth 2.0-standaard. Dit document beschrijft exact hoe een bearer-token in HTTP-verzoeken moet worden meegestuurd en is sindsdien de basis voor talloze implementaties.
Een herkenbaar voorbeeld is "Inloggen met Google", onderdeel van het Google Identity Platform. Wanneer een externe app toegang vraagt tot bijvoorbeeld je Google-foto's, geeft Google een bearer access-token uit dat de app vervolgens gebruikt om beperkte, tijdelijke toegang te krijgen.
Ook AI-diensten leunen op dit mechanisme. Ontwikkelaars die de OpenAI API gebruiken, sturen bij elk verzoek een regel als "Authorization: Bearer sk-..." mee, waarbij de tekenreeks na "sk-" hun persoonlijke API-sleutel is.
In de wereld van cloud-infrastructuur gebruikt Kubernetes, het populaire systeem voor het beheren van containertoepassingen, zogeheten ServiceAccount-tokens: bearer-tokens waarmee een draaiend onderdeel (een "pod") zich bij de centrale Kubernetes API-server kan legitimeren om bijvoorbeeld status op te vragen of acties uit te voeren.
Een recenter voorbeeld is het Model Context Protocol (MCP), dat AI-bedrijf Anthropic eind 2024 introduceerde. MCP is een open standaard waarmee AI-agents op een uniforme manier verbinding maken met externe tools en databronnen; veel MCP-servers beveiligen die verbindingen met bearer-tokens, zodat alleen geautoriseerde agents toegang krijgen.
Hoe ver is de techniek?
Bearer-tokens zijn geen nieuwe of experimentele technologie: sinds de standaardisatie in 2012 zijn ze uitgegroeid tot de facto norm voor authenticatie bij API's. Vrijwel elke moderne webdienst, cloudplatform en AI-service maakt er in een of andere vorm gebruik van.
Toch is het geen perfecte oplossing. De bekendste zwakte volgt direct uit het ontwerp: omdat elke houder van het token toegang krijgt, is diefstal van een token in wezen net zo erg als diefstal van contant geld — wie het heeft, kan het besteden, tot het verloopt of wordt ingetrokken. Dit probleem heeft de afgelopen jaren geleid tot onderzoek naar zogeheten "sender-constrained" tokens, die een token cryptografisch koppelen aan de specifieke client die het heeft aangevraagd. Twee voorbeelden zijn DPoP (Demonstrating Proof-of-Possession, vastgelegd in RFC 9449 in 2023) en tokens die gebonden zijn aan een wederzijds TLS-certificaat (RFC 8705). Bij deze varianten heeft een dief aan het gestolen token alleen niets, omdat ook het bijbehorende cryptografische sleutelmateriaal nodig is.
De adoptie van deze veiligere varianten is echter nog beperkt: de meeste systemen gebruiken vandaag de dag nog altijd "kale" bearer-tokens, met als voornaamste beveiligingsmaatregelen een korte geldigheidsduur (vaak enkele minuten tot uren), aparte langlevende "refresh tokens" om nieuwe toegangstokens op te halen zonder opnieuw in te loggen, verplicht gebruik van HTTPS, en de mogelijkheid om tokens vroegtijdig in te trekken. Het is onzeker hoe snel sender-constrained tokens de huidige praktijk zullen verdringen; voorlopig blijven ze eerder aanvulling dan vervanging.
Wie werken eraan?
De basisstandaarden worden onderhouden door de IETF OAuth Working Group, de internationale werkgroep binnen de Internet Engineering Task Force die verantwoordelijk is voor OAuth-gerelateerde specificaties zoals RFC 6750 en de nieuwere DPoP-standaard.
In de praktijk wordt de techniek gedragen door grote cloud- en identiteitsaanbieders zoals Google, Microsoft (met Entra ID, voorheen Azure Active Directory), Amazon Web Services, en gespecialiseerde identiteitsplatforms als Okta en Auth0. Ook de Kubernetes-gemeenschap, ondergebracht bij de Cloud Native Computing Foundation (CNCF), speelt een rol via het onderhoud van ServiceAccount-tokens.
Binnen AI komen bearer-tokens terug bij bedrijven als Anthropic en OpenAI, die ze gebruiken om toegang tot hun API's en, in het geval van Anthropic's Model Context Protocol, tot AI-agent-tools te beveiligen. Daarnaast buigen onafhankelijke veiligheidsonderzoekers zich voortdurend over nieuwe manieren om tokendiefstal en misbruik te bemoeilijken, werk dat regelmatig terugvloeit in nieuwe IETF-standaarden.