Dit blog presenteert een integratieonderwerp vanuit het perspectief van een projectmanager: tokens. Beheer je integratieprojecten? Ben je ooit verstrikt geraakt in technisch jargon dat slechts door enkele specialisten wordt begrepen, terwijl de tijd om een cruciaal probleem op te lossen wegtikte? Heb je tickets ingediend bij verschillende leveranciers die uiteindelijk weer bij jou terugkwamen? Dan kan dit blog je helpen.
Dit blog behandelt tokenkenmerken en hun gebruik. Een beter begrip vergroot het overzicht en helpt om complexe vraagstukken tot een oplossing te brengen. Begrippen kunnen hier vereenvoudigd zijn, dus uitzonderingen zijn mogelijk. Praktische uitdagingen worden benoemd. Dit blog bouwt voort op een eerder blog over basisconcepten van tokens, dat wordt aanbevolen om eerst te lezen. Als vervolg gaat dit blog dieper op de materie in.
Tokenkenmerken en hun gebruik
Er bestaan verschillende soorten tokens, zoals JSON Web Tokens (JWT), bearer- versus non-bearer tokens, opaque versus self-contained tokens, id_token en (OAUTH) access tokens. Deze kenmerken sluiten elkaar zeker niet uit. Zo is een bearer token vaak self-contained, maar niet noodzakelijkerwijs. De kenmerken en hun gebruik worden hieronder toegelicht.
JWT
Het gebruik van een JSON Web Token (JWT) is gangbaar: eenvoudig te implementeren, waarborgt authenticiteit, voorkomt manipulatie van de handtekening en kan gegevens bevatten zoals autorisatieclaims, geldigheidsduur en meer. JWT is geschikt voor efficiënte verwerking en maakt lokale validatie mogelijk op basis van geheime sleutels. Beveiliging verdient zorgvuldige aandacht om te voorkomen dat tokengegevens op de verkeerde plek terechtkomen. JWT’s werken vooral goed in gedistribueerde systemen en in een microservice-architectuur, die is ontworpen voor onafhankelijke verwerking.
Bearer- versus non-bearer token
Bij een bioscoopkaartje krijgt iedereen die het kaartje toont toegang. In tokenjargon is het equivalent een bearer token. Alleen de geldigheid wordt gecontroleerd, niet (noodzakelijkerwijs) de identiteit.
Het bekendste voorbeeld van een bearer token is de JWT, die doorgaans wordt gebruikt in stateless interacties. Dit vereenvoudigt de afstemming tussen client en server, zonder dat het nodig is om state bij te houden. Dit is vooral nuttig bij grotere transactievolumes.
Wanneer toegang niet mag worden verleend aan iedereen die het token presenteert, moet de identiteit van de aanroeper (gebruiker of applicatie) worden geauthenticeerd. Tokeninspectie dient dat doel (zie het vorige blog).
Opaque versus self-contained token
Het token levert gegevens, via het token zelf en/of via een externe raadpleging.
Een opaque token bestaat meestal uit een betekenisloze tekenreeks. Het krijgt pas betekenis na een externe raadpleging (oftewel server-side validatie, introspectie genoemd), doorgaans bij de tokenuitgever – bijvoorbeeld de OAUTH-autorisatieserver.
Een self-contained token daarentegen maakt het mogelijk om gegevens direct uit het token zelf te halen, zonder externe raadpleging (alleen client-side validatie, inspectie genoemd), door handtekeningverificatie toe te passen, het token te decoderen en de integriteit ervan te controleren. Lokaal opgeslagen sleutels zijn hiervoor voldoende, maar deze sleutels moeten wel veilig worden beheerd.
Hoewel het verlies van een opaque token minder risico’s met zich meebrengt, verbruikt het meer middelen vanwege de benodigde externe raadpleging, wat de prestaties beïnvloedt. Een bearer token zoals een JWT is doorgaans self-contained. OAUTH access tokens daarentegen zijn meestal (maar niet noodzakelijk) opaque.
OAUTH access token
Het OAUTH-protocol kan op veel manieren worden geïmplementeerd. Na het verkrijgen van een id_token als eerste stap (geen onderdeel van OAUTH; zie de sectie over OIDC hieronder), wordt dat token in de tweede stap aangeboden (met gebruik van het OAUTH-protocol). Vervolgens verstrekt de OAUTH-autorisatieserver (vergelijkbaar met de kassa van de bioscoop) een (kortlevend) OAUTH access token, dat wordt meegestuurd bij het aanroepen van de API op de resource server (vergelijkbaar met de bioscoop zelf). Het OAUTH access token heeft betrekking op autorisatie (machtigingen). De resource server verifieert de geldigheid van het OAUTH access token bij de uitgevende autorisatieserver.
De kenmerken van een OAUTH access token zijn doorgaans opaque en non-bearer.
OIDC en OAUTH
OAUTH richt zich op autorisatie en biedt geen gestandaardiseerde manier voor authenticatie. Authenticatie in combinatie met OAUTH is mogelijk, maar dan moet je zelf een authenticatieproces bouwen. Dit kan worden vermeden door OpenID Connect (OIDC) te implementeren. OIDC breidt OAUTH uit met een identiteitslaag voor authenticatiedoeleinden, door het leveren van een id_token en een OAUTH access token. Authenticatie via OIDC is gestandaardiseerd en maakt gebruik van gestandaardiseerde endpoints en gebruikersgegevens, en ondersteunt single sign-on (SSO) over meerdere applicaties. Aan de andere kant voegt OIDC complexiteit toe en kan het als overkill worden beschouwd voor eenvoudige use-cases.
Praktische gevallen
Welke situaties kunnen zich in de praktijk voordoen?
- Organisatorisch. Zorg ervoor dat de juiste vaardigheden betrokken zijn, vooral bij uitgebreide integratieketens. De details tussen de partijen moeten goed op elkaar zijn afgestemd.
- Ontwerp. Bepaal welke tokenkenmerken het beste werken, afhankelijk van beveiligingseisen en (mogelijke) prestatie-uitdagingen:
- Bearer (bijv. JWT) of non-bearer (bijv. OIDC/OAUTH)
- Lokale inspectie (van een self-contained token) of externe raadpleging (opaque token)
- Wat is de bron van de ID (meegegeven in een token of via een lookup)
- Hoe autorisaties passen (machtigingen, OAUTH-autorisatiestromen)
- Inpassing in een integratieketen tussen meerdere partijen
- Realisatie. Implementeer logging/monitoring/alerts zodanig dat tokenproblemen effectief kunnen worden geïdentificeerd.
- Operations. De implementatie van OIDC/OAUTH is afhankelijk van meerdere endpoints (Identity Provider, Authorization Server, Resource Server, …). Frequente technische beschikbaarheidscontroles voorkomen onopgemerkte uitval die de integratieketen blokkeert.
- Uitdagingen. Tokenontwerp moet zorgvuldig worden afgewogen tegen hoge transactievolumes — die laatste geven de voorkeur aan lokale inspectie indien mogelijk. Integratieketens met publieke toegang kunnen extra beveiliging vereisen, wat ook invloed heeft op het tokenontwerp.
Samenvatting
Tokens vormen een essentieel hulpmiddel voor succesvolle integraties. De technologie is bekend, maar je kunt uitdagingen tegenkomen. Dit blog presenteert tokenkenmerken en hun gebruik om je te helpen dergelijke uitdagingen te overwinnen wanneer ze zich voordoen. In vervolgbogs zullen meer onderwerpen worden behandeld.
Herken je deze uitdagingen in je integratieprojecten?
Deel dit blog met je team en gebruik het als basis om token-gerelateerde beslissingen expliciet te maken. Volg deze blogserie voor meer praktische inzichten voor projectmanagers die te maken hebben met complexe integraties.
