Toegangstoken (Access token)

Wat is een toegangstoken (Access token)?

Een toegangstoken (Access token) is een referentie, meestal een reeks karakters, die wordt gebruikt om toegang te krijgen tot beschermde bronnen. In de context van OAuth 2.0 en OpenID Connect (OIDC) kunnen authorization servers toegangstokens (Access tokens) uitgeven aan cliënten (applicaties) na succesvolle authenticatie en autorisatie.

Hoewel de RFC’s voor OAuth 2.0 en OIDC de implementatiedetails van toegangstokens (Access tokens) niet specificeren, zijn er twee gangbare soorten toegangstokens die in de praktijk worden gebruikt:

• Opaque token : Een willekeurige reeks die geen betekenis heeft (“ondoorzichtig”) voor de cliënt. De cliënt biedt het token aan de resource server, die het token valideert bij de authorization server.
• JSON Web Token (JWT) : Een zelfbeheerd token dat claims bevat (bijv. gebruikers-ID, vervaltijd) met een digitale handtekening. De resource server kan het token valideren zonder een extra verzoek te doen aan de authorization server.

Hoe werkt een toegangstoken (Access token)?

Afhankelijk van het type toegangstoken (Access token), kan de stroom van het gebruik van een toegangstoken variëren.

Hier is een vereenvoudigd voorbeeld van het gebruik van een ondoorzichtig toegangstoken (opaque access token):

Hier is een vereenvoudigd voorbeeld van het gebruik van een JWT:

Het verschil tussen de twee typen toegangstokens (Access tokens) is hoe de resource server het token valideert:

• De resource server moet een extra verzoek doen aan de authorization server om een ondoorzichtig token te valideren elke keer dat het een token ontvangt.
• De resource server kan een JWT valideren zonder een extra verzoek te doen aan de authorization server omdat het token alle benodigde informatie bevat en de resource server de publieke sleutel kan cachen van de JSON Web Key Set (JWKS) van de authorization server.

Toegangstokens (Access tokens) zijn meestal van korte duur en hebben een vervaltijd (bijv. 1 uur). Cliënten moeten een nieuw toegangstoken aanvragen wanneer het huidige token verloopt.

Welk type token moet ik gebruiken?

De keuze tussen een ondoorzichtig token en een JWT hangt af van het gebruiksscenario en de veiligheidsvereisten van de applicatie. Hier is een vergelijking van de twee typen tokens:

	Ondoorzichtig Token	JWT
Formaat	Willekeurige reeks	Zelfbeheerde JSON-objecten
Prestatie	Vereist een extra verzoek	Snellere validatie
Zelfbeheerd	Nee	Ja
Tokensize	Kleiner	Groter
Intrekking	Onmiddellijk	Vereist tokenverloop of een interactie met authorization server
Uitbreidbaarheid	Beperkt	Aangepaste claims
Stateless	Nee	Ja
Veiligheid	Vereist tokenvalidatie	Vereist handtekeningvalidatie
Standaard	Nee	Ja (RFC 7519)

Voor meer informatie over het kiezen tussen de twee typen tokens, zie Opaque token vs JWT .

De rollen van de authorization server en de resource server

In de meeste gevallen heeft de Autorisatieserver (Authorization server) de volgende verantwoordelijkheden:

• Geeft toegangstokens (Access tokens) uit aan cliënten na succesvolle authenticatie en autorisatie. De authorization server kan het toegangsniveau verkleinen (de scopes verkleinen tot een subset) of het tokenverzoek afwijzen op basis van de toegangspolicies (bijv. gebruikersinstemming, Role-gebaseerde toegangscontrole (Role-based access control, RBAC) , Attribuut-gebaseerde toegangscontrole (Attribute-based access control, ABAC) ).
• Controleert of het toegangstoken door de authorization server is uitgegeven en niet verlopen of ingetrokken is ( Token introspectie (Token introspection) ).
• Biedt informatie over het token (bijv. scopes, vervaltijd) via token introspection of Userinfo-endpoint .

Je zult merken dat de authorization server de betekenis van het toegangstoken niet interpreteert. Bijvoorbeeld, het toegangstoken kan een scope read:orders bevatten, maar de authorization server weet niet wat de scope betekent. De resource server is verantwoordelijk voor het interpreteren van het toegangstoken en het afdwingen van de Toegangsbeheer (Access control) op basis van de scopes van het token. Dat wil zeggen dat de Resource server meestal de volgende verantwoordelijkheden heeft:

• Valideer de claims in het toegangstoken (bijv. vervaltijd, resource indicator, scopes).
• Dwingt de toegangspolicy af op basis van de claims van het token (meestal scopes).
• Biedt de beschermde bronnen als het toegangstoken geldig is.

Levenscyclus van een toegangstoken (Access token)

De levenscyclus van een toegangstoken bestaat meestal uit de volgende fasen:

Zie ook

• Opaque token
• JSON Web Token (JWT)
• Token introspectie (Token introspection)
• Userinfo-endpoint
• Toegangsbeheer (Access control)