JWT Decoder

Wat is een JWT?

Een JSON Web Token (JWT, uitgesproken "jot") is een compact, ondertekend JSON-object gedefinieerd in RFC 7519. Het draagt claims tussen twee partijen, doorgaans tussen een auth-server en een API. De server geeft het token uit na succesvolle authenticatie, en de client hangt het aan elke API-call via de `Authorization: Bearer ...` header.

JWTs bestaan uit drie base64url-gecodeerde delen, samengevoegd door punten. Ze zijn niet versleuteld, alleen ondertekend. Iedereen die het token heeft, kan de inhoud lezen, daarom mogen wachtwoorden en andere geheimen nooit in de payload staan.

Het voordeel ten opzichte van server-side sessies: een JWT is self-contained. Een API-server kan het token valideren en rechten extraheren zonder contact op te nemen met de auth-server of een sessie-store te bevragen. Dat schaalt horizontaal uitstekend, maar wel ten koste van het vroegtijdig kunnen revoken van individuele tokens.

Header, payload, signature uitgelegd

Elk JWT heeft drie delen, samengevoegd door losse punten:

• Header: klein JSON-object met `alg` (algoritme, bv. HS256, RS256, ES256) en `typ` (meestal "JWT"). Soms ook `kid` (key ID) als hint over welke sleutel is gebruikt om te ondertekenen.
• Payload: JSON-object dat de claims bevat. Standaardvelden zijn `iss` (issuer), `sub` (subject), `aud` (audience), `exp` (expiration), `nbf` (not before), `iat` (issued at) en `jti` (uniek token-ID). Eigen velden zijn ernaast toegestaan.
• Signature: berekend over `base64url(header) + "." + base64url(payload)` met het geconfigureerde algoritme. Beschermt de integriteit: zonder de sleutel kan de inhoud niet onopgemerkt worden gewijzigd.

Belangrijk: base64url is codering, geen versleuteling. De header en payload zijn voor elke waarnemer leesbaar.

JWT vs. sessiecookies

Beide benaderingen behouden een geauthenticeerde toestand, maar op verschillende manieren:

• Sessiecookie: ondoorzichtige ID, de server gebruikt die om de volledige toestand op te zoeken in de sessie-store. Revocatie is direct, maar elke aanvraag kost een lookup.
• JWT: bevat de toestand zelf, alleen beveiligd door handtekening. Geen lookup nodig, perfect voor microservice-architecturen, maar revocatie vóór expiry vereist een allow/deny list.
• Grootte: JWTs zijn doorgaans 300 tot 1500 bytes. Sessie-IDs zijn meestal rond 32 bytes. Bij veel API-calls telt de JWT-grootte op in bandbreedte.
• Storage: cookies (HttpOnly, Secure, SameSite) zijn de veiligere opslaglocatie voor browsers. localStorage is blootgesteld aan XSS.

Vuistregel: blijf bij sessies voor pure server-apps, gebruik JWTs voor API-gateways en mobiele backends, idealiter met korte lifetimes en een refresh-token-flow.

JWT-beveiliging: wat te doen met `algorithm: none`?

JWTs hebben de afgelopen jaren verschillende spectaculaire bibliotheekbugs gehad. De grootste valkuilen:

• `alg: none`: verschillende bibliotheken accepteerden vroeger ondertekende tokens zodra de header dat beweerde. Oplossing: laat `none` nooit toe, hardcode het toegestane algoritme op de server.
• HS256/RS256-verwarring: een aanvaller ondertekent een token met de RSA-publieke sleutel als HMAC-secret, de server valideert het als HS256 in plaats van RS256, en wordt voor de gek gehouden. Verdediging: het toegestane `alg` ligt vast op de server.
• `kid` injection: het `kid`-veld wijst naar een sleutel, maar als het niet wordt gesanitiseerd kan het leiden tot path traversal of SQL-injectie. Behandel de waarde als untrusted input.
• Zwakke secrets: HS256-tokens met "secret" of "password" als sleutel vallen in seconden door brute force. Gebruik minstens 256 willekeurige bits, idealiter van `crypto.getRandomValues()` of `/dev/urandom`.
• Lange lifetime: elk uitgegeven JWT is geldig tot expiratie, ook nadat een gebruiker is "uitgelogd". Gebruik korte lifetimes (15 min) plus een refresh-token-flow, of een deny list voor gevoelige endpoints.

De OWASP-cheatsheets en RFC 8725 (JWT Best Current Practices) zijn verplichte kost.

Hoe valideer ik een JWT?

Een volledige validatie omvat veel meer dan alleen de handtekening. Volgorde in servercode:

• Parse de header, controleer `alg` tegen een allowlist (bv. alleen RS256).
• Verifieer de handtekening met de sleutel die past bij de issuerconfiguratie. Bij JWKS, gebruik `kid` voor de lookup, maar whitelist eerst de waarden.
• Controleer standaard claims: `iss` komt overeen met de verwachte issuer, `aud` bevat uw eigen audience, `exp` ligt in de toekomst, `nbf` en `iat` liggen in het verleden (sta een kleine clock-skew tolerantie toe).
• Valideer uw eigen claims (rollen, tenant-ID, scopes) tegen uw bedrijfsmodel.
• Als vroegtijdige revocatie vereist is, controleer dan de deny / logout list.

Vertrouw op een gevestigde bibliotheek (jose, jjwt, jsonwebtoken etc.), niet op zelfgeschreven code. Cryptografie is geen hobbyproject.

Host uw auth-backend bij KernelHost

Een JWT-issuer en resource-server hebben een betrouwbare backend met lage latency nodig. KernelHost draait eigen VPS- en dedicated servers in Frankfurt FRA01 met DDoS-bescherming, IPv4 + IPv6 en 1 Gbit/s uplink. Lage RTT naar Europese eindgebruikers, eerlijke prijzen, geen vendor lock-in. Bedrijfszetel Wenen (AT), datacenter Frankfurt (DE).

JWT FAQ