ID-token versus access-token: het cruciale verschil in OpenID Connect

By Mirko Peters · 2026-10-28

Ontdek de belangrijkste verschillen tussen ID-tokens en access-tokens in OpenID Connect, en leer waarom ze door elkaar halen ernstige beveiligingslekken veroorzaakt.

Automatically translated with AI from the original post. Read the English original

Begrijpen wat het verschil is tussen een ID-token en een access-token is essentieel voor ontwikkelaars en IT-beheerders die met moderne authenticatie werken. OAuth 2.0 regelt de machtigingen, terwijl OpenID Connect het ID-token introduceert om de identiteit van de gebruiker te bevestigen. Wie deze twee verschillende tokens door elkaar haalt, introduceert kritieke beveiligingslekken in cloudapplicaties.

Belangrijkste punten

• ID-tokens bewijzen de identiteit van een gebruiker, terwijl access-tokens autorisatie en machtigingen verlenen.
• Deze twee tokens door elkaar halen is een belangrijke fout in de beveiliging van zelfgebouwde applicaties.
• OpenID Connect legt een laag voor identiteitsbevestiging bovenop het OAuth 2.0-raamwerk.
• Access-tokens kunnen worden ingetrokken, wat een veiliger alternatief is dan het opslaan van wachtwoorden.
• Apps moeten inkomende ID-tokens cryptografisch verifiëren in plaats van ze blindelings te vertrouwen.

Het kernprobleem: identiteit versus autorisatie

In de evolutie van moderne webapplicaties raken ontwikkelaars regelmatig in de war over hoe gebruikers zich aanmelden en hoe diezelfde gebruikers met de onderliggende gegevens omgaan. Veel van die verwarring komt voort uit overlappende terminologie in de identiteitswereld. Toen applicaties zich snel over het web begonnen uit te breiden, vormden alleen gebruikersnaam-en-wachtwoordcombinaties een enorme beveiligingsknelpunt. Gebruikers raakten uitgeput van het beheren van tientallen unieke inloggegevens, wat leidde tot zwakke wachtwoorden die op meerdere platforms werden hergebruikt.

Om een deel van dit probleem op te lossen, kwam OAuth 2.0 in beeld. OAuth 2.0 is echter nooit ontworpen om te bepalen wie iemand is. Het doel is uitsluitend om toestemmingen uit te geven, de zogenaamde access-tokens, waarmee een applicatie namens een gebruiker bij specifieke gegevensendpoints kan komen. Een access-token beschrijft wat een applicatie mag doen, maar zwijgt volledig over de identiteit van de persoon die het bezit. Door deze fundamentele leemte moesten bedrijven die single sign-on wilden bouwen hun eigen identiteitscontroles aan OAuth koppelen. Dat leidde tot gefragmenteerde implementaties die zelden met elkaar overeenkwamen.

OpenID Connect overbrugde precies deze leemte door een gestandaardiseerde laag te introduceren die speciaal is bedoeld voor authenticatie. Met een tweede token naast het traditionele access-token scheidt OpenID Connect op heldere wijze de vraag naar identiteit van de vraag naar machtigingen. Deze twee begrippen gescheiden houden is vandaag de belangrijkste mentaliteitsverandering voor iedereen die cloudapplicaties bouwt of controleert.

Anatomie van het ID-token: wat er binnenin zit

Wanneer een gebruiker op de knop "Aanmelden met Microsoft" klikt, verwerkt de identity provider de inloggegevens, handelt de vereisten voor multifactorauthenticatie af en stuurt de gebruiker uiteindelijk terug naar de applicatie, samen met een ID-token. Dit token is verpakt als een JSON Web Token, meestal afgekort als JWT en uitgesproken als "jot". Op het eerste gezicht lijkt een JWT op een ondoordringbare reeks tekens die door punten worden gescheiden. De interne structuur is echter verrassend eenvoudig zodra je het decodeert.

In een ID-token vind je een handvol standaardclaims, elk met een duidelijk doel:

• Issuer: Identificeert de specifieke identity provider (zoals Microsoft Entra ID) die het token heeft gegenereerd en ondertekend.
• Subject (sub): Dient als unieke, onveranderlijke identifier voor de gebruiker. Cruciaal is dat deze waarde niet verandert, ook niet als de gebruiker zijn weergavenaam of e-mailadres bijwerkt.
• Audience (aud): Geeft aan voor welke exacte applicatie het token is aangemaakt. Zo wordt voorkomen dat een token dat bedoeld is voor de ene app kwaadwillig wordt onderschept en door een andere app wordt hergebruikt.
• Tijdstempels: Geven aan wanneer het token is uitgegeven, wanneer het verloopt en het exacte moment waarop de gebruiker zich heeft geauthenticeerd.
• Nonce: Fungeert als een veilig ontvangstnummer dat het resulterende token koppelt aan de specifieke aanmeldsessie die het verzoek heeft gestart. Zo worden replay-aanvallen effectief geblokkeerd.

Cruciaal is dat het hele pakket wordt ondertekend met de privésleutel van de provider. De ontvangende applicatie valideert deze handtekening met de bijbehorende publieke sleutel die de provider publiceert. Zonder deze cryptografische verificatie is een ID-token niet meer dan een ongeverifieerd briefje dat tussen partijen wordt doorgegeven.

Het gevaar van identiteit behandelen als toegang

Een van de gevaarlijkste anti-patronen in applicatieontwikkeling is het behandelen van een ID-token als toegangssleutel. Omdat een ID-token bevestigt dat een gebruiker John Doe is van een bepaalde organisatie, maken onervaren ontwikkelaars soms de fout om die bevestiging te gebruiken om beheerdersrechten of onbeperkte databasetoegang te verlenen. Dit getuigt van een fundamenteel misverstand over de architectuur.

Een ID-token vertelt alleen wie er voor de voordeur staat; het zegt niets over de vraag of die persoon elke kamer in het huis mag betreden of op een specifieke beheerknop mag klikken. Autorisatielogica moet door de applicatie afzonderlijk worden afgehandeld, bijvoorbeeld met role-based access control of vergelijkbare mechanismen, waarbij de geverifieerde identiteit het startpunt is en niet het definitieve autorisatiebesluit.

Daarnaast maken applicaties vaak de fout om binnenkomende ID-tokens te accepteren zonder de juiste validatiecontroles uit te voeren. Een token blindelings vertrouwen omdat een bibliotheek het op de achtergrond heeft verwerkt, laat systemen kwetsbaar voor vervalste gegevens. Het valideren van de handtekening, het controleren van de vervaltijdstempels en het verifiëren van de audience-claim zijn onmisbare stappen voor een veilige opzet.

Conclusie

Het beheersen van de grens tussen identiteit en autorisatie helpt om moderne cloudarchitectuur te doorgronden. Door ID-tokens strikt te richten op het bewijzen van wie er achter het toetsenbord zit, en access-tokens te laten bepalen welke acties zijn toegestaan, kunnen ontwikkelaars robuuste en veilige integraties bouwen met platforms zoals Microsoft Entra ID. Wil je een uitgebreide uitleg van deze concepten horen en zien hoe moderne aanmeldworkflows in het Microsoft-ecosysteem werken? Bekijk dan de volledige discussie. Luister de volledige aflevering en duik vandaag nog dieper in de mechanismen van cloudidentiteit!

Veelgestelde vragen

Kan een ID-token worden gebruikt om API's aan te roepen of toegang te krijgen tot beschermde resources?

Nee. Een ID-token bevat alleen identiteitsclaims over wie de gebruiker is. Om API's aan te roepen of toegang te krijgen tot beschermde resources, moet een applicatie een access-token gebruiken dat via OAuth 2.0 is uitgegeven.

Waarom gebruiken OpenID Connect en OAuth 2.0 aparte tokens?

Door identiteit en autorisatie te scheiden, kunnen applicaties controleren wie er inlogt zonder die applicatie carte blanche te geven om de onderliggende gegevens of resources van de gebruiker te manipuleren.

Wat gebeurt er als een applicatie een ID-token accepteert zonder de handtekening te controleren?

Als de handtekening niet wordt gecontroleerd, is de applicatie kwetsbaar voor vervalste tokens, want iedereen kan een zelfgemaakte tekenreeks genereren die beweert een geldige gebruiker te zijn.

Waar past de 'nonce'-waarde in de tokenuitwisseling?

De nonce is een willekeurige tekenreeks die aan het begin van de aanmeldstroom wordt gegenereerd en in het ID-token wordt opgenomen. Zo kan de applicatie replay-aanvallen voorkomen.