Een REST API beveiligen betekent bij elke request drie vragen beantwoorden: wie ben je (authenticatie), wat mag je doen (autorisatie), en is het kanaal privé (transport). Omdat REST stateless is, moeten credentials met elke request meereizen in plaats van in een serversessie te leven.
Alles hieronder gaat uit van . Zonder dat reizen tokens en API-keys in plaintext en kunnen ze worden gesnift. Dit is niet onderhandelbaar — een bearer token over HTTP is een gelekt token.
API-keys — een statisch geheim in een header. Eenvoudig; goed voor server-to-server en het identificeren van een applicatie, niet een user. Op zichzelf zwak (geen vervaltijd, geen scope) tenzij gecombineerd met meer.
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
OAuth 2.0 — de standaard voor gedelegeerde toegang ("laat App X mijn data lezen zonder mijn wachtwoord"). De app verkrijgt een access token via een flow (bv. Authorization Code) en stuurt het als een bearer token. Zo werken "Sign in with Google" en integraties van derden.
JWT (JSON Web Token) — een gangbaar formaat voor tokens: een ondertekend, zelfvoorzienend token dat claims draagt (user id, rollen, vervaltijd). De server verifieert de handtekening — geen database-lookup nodig, wat past bij stateless REST.
header.payload.signature (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
Authenticatie bewijst identiteit; autorisatie beslist over toegang. Tokens dragen scopes (orders:read, orders:write) of rollen; de server controleert ze per endpoint en retourneert 403 Forbidden wanneer ze onvoldoende zijn (versus 401 voor ontbrekende/ongeldige auth).
No/invalid token → 401 Unauthorized
Valid token, no scope → 403 Forbidden
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
Beveiliging is waar een kleine fout een breach wordt, dus interviewers gebruiken dit om te zien of je er structureel over redeneert in plaats van buzzwords op te dreunen. Het signaal dat ze zoeken is dat je de drie lagen scheidt — transport (HTTPS, altijd), authenticatie (identiteit bewijzen, stateless, via bearer tokens/JWT/OAuth), en autorisatie (scopes en least privilege) — en dat je ze niet door elkaar haalt, bv. 401 correct gebruiken voor "niet geauthenticeerd" versus 403 voor "geauthenticeerd maar niet toegestaan". Sterke antwoorden tonen besef van de praktische afwegingen: JWT's zijn handig en stateless maar moeilijk in te trekken voordat ze verlopen (vandaar korte levensduur plus refresh tokens), API-keys identificeren apps, geen users, en OAuth bestaat juist zodat users hun wachtwoord niet aan derden geven. Het koppelen aan de statelessness van REST — credentials bij elke request, geen serversessie — laat zien dat je begrijpt waarom API-beveiliging eruitziet zoals ze doet.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren