JWT Decoder
JSON Web Tokens decoderen en inspecteren
JWT Token
Wat is een JWT (JSON Web Token)?
Een JSON Web Token (JWT) is een compact, URL-veilig tokenformaat gedefinieerd in RFC 7519. Het codeert een set claims als een JSON-object, ondertekent dit vervolgens — en versleutelt het optioneel — zodat de ontvanger kan verifiëren dat de gegevens niet zijn gemanipuleerd. JWT's zijn de de facto standaard voor staatloze authenticatie in REST API's, single-sign-on-systemen en microservice-autorisatie.
JWT-anatomie: Header · Payload · Signature
Elke JWT bestaat uit drie base64url-gecodeerde segmenten gescheiden door punten. De header en payload zijn gewone JSON — leesbaar voor iedereen — terwijl de signature een cryptografische waarde is die alleen geverifieerd kan worden met de juiste sleutel.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "user123",
"name": "Alice",
"role": "admin",
"iat": 1717200000,
"exp": 1717203600
}Waarom een JWT-decoder gebruiken?
Ruwe JWT's zien eruit als willekeurige tekst. Dit hulpmiddel geeft de header en payload direct weer als geformatteerde JSON, zodat u claims kunt inspecteren, vervaltijden kunt controleren en algoritmerekeuzes kunt controleren zonder één regel code te schrijven.
Standaard JWT-claims referentie
RFC 7519 definieert zeven geregistreerde claimnamen. Deze zijn niet verplicht, maar hun gebruik wordt sterk aanbevolen voor interoperabiliteit. U kunt aangepaste claims toevoegen aan de payload.
| Claim | Beschrijving | Type |
|---|---|---|
| iss | Uitgever — Identificeert wie het token heeft uitgegeven — bijv. de URL van uw auth-server of de applicatienaam. | string |
| sub | Onderwerp — Identificeert de principal waarover de JWT gaat — doorgaans een gebruikers-ID of serviceaccount. | string |
| aud | Publiek — Identificeert de beoogde ontvangers. De ontvangende partij moet verifiëren dat dit overeenkomt met hun identifier. | string | string[] |
| exp | Vervaltijd — Unix-tijdstempel waarna het token niet meer geaccepteerd mag worden. Stel dit altijd in om schade door een gestolen token te beperken. | number |
| nbf | Niet voor — Unix-tijdstempel vóór welke het token niet geaccepteerd mag worden. Nuttig voor het plannen van toekomstig gedateerde tokens. | number |
| iat | Uitgegeven op — Unix-tijdstempel waarop het token is uitgegeven. Gebruikt om de leeftijd van het token te berekenen. | number |
| jti | JWT ID — Een unieke identifier voor het token. Maakt intrekking mogelijk door gebruikte JTI-waarden server-side op te slaan en te controleren. | string |
JWT-ondertekeningsalgoritmen
De alg-headerclaim geeft aan welk algoritme het token heeft ondertekend. De keuze beïnvloedt beveiliging, prestaties en of diensten van derden tokens kunnen verifiëren zonder de privésleutel.
| Algoritme | Familie | Sleuteltype | Opmerkingen |
|---|---|---|---|
| HS256 | HMAC | Symmetric | Meest gebruikelijk. Gedeeld geheim — iedereen met het geheim kan ondertekenen en verifiëren. |
| HS384 | HMAC | Symmetric | Sterkere HMAC-variant; matige prestatiekosten. |
| HS512 | HMAC | Symmetric | Sterkste HMAC-variant. |
| RS256 | RSA | Asymmetric | Meest gebruikte asymmetrische algoritme (Google, Auth0, Okta). Publieke sleutel verifieert zonder privésleutel. |
| RS384 | RSA | Asymmetric | RS-variant met hogere beveiliging. |
| RS512 | RSA | Asymmetric | Sterkste RS-variant. |
| ES256 | ECDSA | Asymmetric | Elliptische curve — kortere handtekeningen dan RSA, populair op mobiel en IoT. |
| PS256 | RSA-PSS | Asymmetric | RSA-PSS: moderner en veiliger dan op PKCS1v1.5 gebaseerde RS256. |
| none | — | — | Geen handtekening — kritiek gevaarlijk. Accepteer nooit tokens met alg: none in productie. |
Beveiligingsoverwegingen
Een JWT decoderen is altijd veilig. Een JWT vertrouwen zonder goede handtekeningverificatie is dat niet. Houd deze regels in gedachten wanneer u tokens in uw applicatie gebruikt.
- –Een JWT decoderen en inspecteren in ontwikkelaarstools of dit hulpmiddel
- –exp, iat en nbf gebruiken om de levensduur van het token te begrijpen
- –Payload-claims loggen voor debugging (gevoelige persoonsgegevens weglaten)
- –De alg-header lezen om te begrijpen hoe het token is ondertekend
- –Claims in de payload vertrouwen zonder de handtekening server-side te verifiëren
- –Tokens accepteren met alg: none — dit betekent helemaal geen handtekening
- –Toegangstokens opslaan in localStorage in toepassingen met hoge beveiliging (geef de voorkeur aan httpOnly-cookies)
- –exp ver in de toekomst instellen voor tokens die gevoelige machtigingen bevatten
Veelvoorkomende gebruiksscenario's
JWT decoderen in code
De header en payload zijn base64url-gecodeerd — keer de codering gewoon om. Base64url vervangt + door - en / door _, en laat = opvulling weg. Alleen de signature heeft de geheime sleutel nodig.
function decodeJWT(token) {
const [, payload] = token.split('.')
const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
return JSON.parse(json)
}const [, payload] = token.split('.')
const decoded = JSON.parse(
Buffer.from(payload, 'base64url').toString()
)import base64, json
def decode_jwt(token):
payload = token.split('.')[1]
padding = '=' * (-len(payload) % 4)
return json.loads(base64.urlsafe_b64decode(payload + padding))TOKEN="eyJhbGc..." echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .