Deze blog presenteert een integratieonderwerp vanuit het perspectief van een projectmanager: tokens. Beheer je integratieprojecten? Raakte je ooit verstrikt in technisch jargon dat slechts door enkele specialisten wordt begrepen, terwijl de tijd om een kernprobleem op te lossen wegtikte? Heb je tickets ingediend bij verschillende leveranciers, die uiteindelijk weer bij jou terugkwamen? Dan kan deze blog helpen.
Deze blog behandelt basisconcepten van tokens. Een beter begrip vergroot het overzicht en helpt om complexe vraagstukken tot een oplossing te brengen. Begrippen kunnen hier vereenvoudigd zijn weergegeven, waardoor uitzonderingen mogelijk zijn. Praktische uitdagingen worden benoemd. Wie meer detail wil, kan veel aanvullende informatie op internet vinden. Een vervolgartikel behandelt token-eigenschappen.
Tokens
Tokens worden voornamelijk voor twee doeleinden gebruikt.
- Een webapplicatie, toegankelijk via een browser, waarmee een menselijke gebruiker kan interageren
- Een API, waarmee applicaties/mobiele apps/services met een andere kunnen communiceren
Binnen die context verleent een externe applicatie toegang via beide:
- authenticatie – het verifiëren van de identiteit van een gebruiker, waarvoor een gebruikersnaam/wachtwoord of een wachtwoordloos beleid nodig is
- autorisatie – het controleren van toegangsrechten tot geselecteerde resources
Traditioneel was authenticatie met gebruikersnaam en wachtwoord voldoende. Tegenwoordig is een robuustere authenticatiemethode beschikbaar, met een kortere geldigheidsduur en verhoogde beveiliging. Tokens zijn ontworpen om dit gat te vullen. Hoewel het concept eenvoudig is, gaat er een hele wereld achter schuil. Deze blog verkent de basisconcepten.
Metafoor
Een token is te vergelijken met een bioscoopbezoek: je koopt een kaartje aan de kassa, terwijl de daadwerkelijke toegang gescheiden is. Net als een bioscoopkaartje is een token “kortlevend”, om risico’s te beperken. Zodra het token is verlopen, kan het niet meer worden gebruikt. Validatie van een token vereist een vertrouwensketen, vergelijkbaar met TLS-certificaten.
Als er meerdere films draaien in de bioscoop, vermeldt je kaartje de juiste film (autorisatie). Op dezelfde manier kan een resource server meerdere resources ‘in de aanbieding’ hebben, waarvoor correcte autorisatie nodig is.
Authenticatie
Een belangrijk doel van tokens is het authenticeren van de gebruiker of clientapplicatie. Om toegang te krijgen tot een webapplicatie volstaat meestal een login en wachtwoord, eventueel met aanvullende multi-factor authenticatie (MFA). Om echter een clientapplicatie toegang te verlenen tot een API, is geavanceerdere authenticatie nodig. De ID kan op verschillende manieren worden ondergebracht, waaronder:
- Een JSON Web Token (JWT). Nadat de gebruiker is ingelogd, verstrekt de responderende server een JWT met daarin de geauthenticeerde ID. Vervolgens presenteert de aanroeper dit token aan een API, en valideert de responderende server het token.
- Een ID-token: de gebruiker logt in via een applicatie van een derde partij (bijv. Google of Facebook), wat resulteert in een ID-token. De aanroeper gebruikt dat ID-token om bij de autorisatieserver een OAUTH access token te verkrijgen, met een korte geldigheidsduur, om toegang te krijgen tot de resource server.
- Een sessietoken (met stateful informatie), meestal opgeslagen als cookie bij de client. Dit wordt normaal gesproken door een browser gebruikt om toegang te krijgen tot een externe applicatie.
Meer details over token-eigenschappen worden gegeven in een vervolgartikel.
Inspectie & validatie
Een token bevat of representeert ID-gegevens, maar mogelijk ook andere data, zoals autorisatie-claims. Gegevens kunnen alleen worden verkregen door het token te inspecteren, aan server- en/of clientzijde. Het belangrijkste doel van tokeninspectie is validatie van het token, op verschillende niveaus, afhankelijk van het gebruiksscenario:
- formaatcontrole, om correct gebruik te verifiëren
- handtekeningcontrole, om integriteit en authenticiteit te verifiëren
- verloopcontrole, om te bepalen of het token geldig is
- identiteitsinformatie (claims over de gebruiker)
- claim-extractie (bijv. intended audience-claim, autorisatie-claims)
- controle van het tokentype (access- of refresh-token)
In sommige gevallen maakt het ontwerp client-side validatie (alleen) mogelijk, wanneer het token alle benodigde data bevat, om externe lookups te vermijden die de performance kunnen beïnvloeden. In het geval van externe lookups, bijvoorbeeld om toegekende rechten op te halen, moet het ontwerp voorzien in server-side validatie.
Autorisatie
Historisch werd autorisatie opgehaald uit (gekoppeld aan) het geïdentificeerde gebruikersaccount. Inmiddels is erkend dat het opnemen van autorisatiegegevens in een token verschillende voordelen biedt, zoals:
- extra beveiliging, bijvoorbeeld het herkennen van beperkingen vóórdat toegang wordt verleend
- dynamische rechten, afgedwongen door het token
- directe bepaling van rechten, zonder database-lookup en zonder de noodzaak om state te onderhouden
Refresh token
Tokens zijn kortlevend. Om herhaald inloggen te voorkomen, wordt een langlevend refresh-token meegeleverd met het kortlevende access-token. Na het verlopen van het access-token kan het refresh-token worden gebruikt (indien nog geldig) om een nieuw access-token aan te vragen. Beschouw dit als een ‘abonnementstoken’.
Praktijkgevallen
Welke situaties kunnen zich in de praktijk voordoen?
- Organisatorisch. Betrek de juiste vaardigheden, gericht op business requirements, ontwerp en technische expertise. Omissies zullen vertraging veroorzaken.
- Ontwerp. Laat de architect(en) de beste tokenoplossing selecteren, met aandacht voor beveiliging en performance. Als ID-tokens elders ontstaan (bijv. Google of Facebook) en hergebruikt worden in een integratieketen, zorg dan voor architecturale afstemming.
- Realisatie. Details zijn belangrijk, zoals token-claims, OAUTH-autorisatiestromen en afstemming met applicatierollen.
- Beheer. Besteed aandacht aan sleutelbeheer voor encoderen/decoderen en tokenvalidatie, met veilige opslag. Adequate vervaltijden worden sterk aanbevolen. Het hele doel van tokengebruik wordt tenietgedaan als een lange geldigheidsduur wordt gedefinieerd — ‘voor het gemak’.
- Uitdagingen. Er zijn verschillende tokenmechanismen beschikbaar. Wees echter voorzichtig: integraties raken twee of meer partijen. Controleer de compatibiliteit van de betrokken applicaties. Zo niet, dan blijven er minder opties over.
Samenvatting
Tokens vormen een essentieel hulpmiddel voor succesvolle integraties. De technologie is bekend, maar je kunt uitdagingen tegenkomen. Deze blog presenteert basisconcepten van tokens om je te helpen uitdagingen te overwinnen wanneer die zich voordoen. Een vervolgartikel biedt meer detail over token-eigenschappen.
