PK Systems PK Systems
Encoders & decoders

JWT-ondertekenaar

Maak en onderteken JSON Web Tokens met HS256, HS384 of HS512. Plak een geheim, voer claims in en kopieer het resultaat.

JWT-ondertekenaar

HS* gebruikt een gedeeld geheim; RS256 en ES256 gebruiken een asymmetrisch sleutelpaar.

Het alg-veld synchroniseert automatisch met de bovenstaande selector.

Standaardclaims: sub, iss, aud, iat, exp, nbf, jti.

Gebruik in productie 256+ bits aan willekeurige entropie. Hergebruik geen wachtwoorden.

Ondertekende JWT


            
        

Wat is JWT-ondertekening?

Een JSON Web Token (JWT) is een compacte, URL-veilige manier om claims tussen twee partijen te transporteren. Het bestaat uit drie Base64URL-gecodeerde delen die samengevoegd worden met punten: een header die het algoritme noemt, een payload met willekeurige JSON-claims, en een handtekening die berekend is over header.payload met een sleutel. De ontvanger berekent de handtekening opnieuw en wijst de token af als deze niet overeenkomt. JWT's zijn populair voor stateless authenticatie omdat servers geen sessies hoeven te onthouden — elk verzoek draagt zijn eigen bewijs. De keerzijde is dat je een token na uitgifte niet kunt intrekken zonder een aparte intrekkingslijst, en elk gelekt geheim of elke gelekte sleutel compromitteert elke token die ermee is ondertekend. Deze tool draait volledig op je apparaat — je geheimen, ondertekensleutels en tokens verlaten de pagina niet, gaan niet naar onze servers, en worden niet opgeslagen, geïndexeerd, gelogd of gedeeld. Die privacygarantie is belangrijk omdat een enkele toetsaanslag-lek van een JWT-ondertekengeheim elk gebruikersaccount kan compromitteren waarvoor er tokens worden uitgegeven.

Hoe gebruik je de ondertekenaar

Kies het algoritme dat past bij je omgeving, plak de header en payload (of gebruik de standaardwaarden als sjabloon) en klik op Ondertekenen. Voor RS256 en ES256 kun je een nieuw sleutelpaar op de pagina genereren; voor HS256 lever je een gedeeld geheim aan. Om te verifiëren schakel je naar verificatiemodus, plak je de token en het bijbehorende geheim of de publieke sleutel, en klik je op Verifiëren. De gedecodeerde payload verschijnt bij succes in het verdict-vak.

Best practices

Stel altijd exp (vervaltijd) in op productietokens. Accepteer nooit het algoritme dat in de header staat zonder een allowlist — de klassieke alg=none-aanval misbruikt servers die de header vertrouwen. Roteer ondertekensleutels regelmatig, bewaar private sleutels in een HSM of secrets manager, en behandel HMAC-geheimen als wachtwoorden. Voor browsers en mobiele apps geef je de voorkeur aan kortlevende JWT's gecombineerd met refresh-tokens die in HttpOnly-cookies worden opgeslagen.

Algoritme-vergelijking

Alg Familie Use case
HS256HMAC + SHA-256Interne services die één gedeeld geheim delen. Snel, simpel.
HS384HMAC + SHA-384Interne services die één gedeeld geheim delen. Snel, simpel.
HS512HMAC + SHA-512Interne services die één gedeeld geheim delen. Snel, simpel.
RS256RSA + SHA-256Publieke API's die de publieke sleutel verspreiden voor verificatie.
ES256ECDSA P-256 + SHA-256Net als RS256 maar met kortere handtekeningen en moderne elliptische krommen.

Veelgestelde vragen

Wordt er iets naar je server verstuurd?
Nee. Het ondertekenen en verifiëren gebeurt volledig op je apparaat met de ingebouwde cryptografie van je browser. Je geheimen, sleutels en tokens verlaten de pagina niet, gaan niet naar onze servers, en worden niet opgeslagen, geïndexeerd, gelogd of gedeeld.
Wat is het verschil tussen HS256 en RS256?
HS256 gebruikt één gedeeld geheim voor zowel ondertekenen als verifiëren — iedereen die kan verifiëren kan ook ondertekenen. RS256 gebruikt een RSA-sleutelpaar: de private sleutel ondertekent, de publieke sleutel verifieert, dus de verifiërende partij heeft het ondertekenmateriaal niet nodig.
Kan ik dit gebruiken voor productiesleutels?
Je kunt hier ontwikkelsleutels genereren, maar productieprivésleutels horen in je KMS of HSM thuis. Een echte productiesleutel in een webpagina plakken is een serieus beveiligingsincident.
Waarom mislukt de verificatie van mijn token?
Veelvoorkomende oorzaken: verkeerd algoritme in de dropdown ten opzichte van de tokenheader, niet-overeenkomend geheim of publieke sleutel, verlopen (exp) of nog-niet-geldige (nbf) token, gemanipuleerde payload, of een kopieer-en-plakactie die witruimte introduceerde.
Welke codering gebruikt de payload?
JWT serialiseert de JSON-payload naar UTF-8 en codeert deze vervolgens met Base64URL. JSON-sleutels zijn hoofdlettergevoelig. Strings binnen de payload moeten UTF-8 zijn.
Zijn JWT's versleuteld?
Standaard JWT's zijn ondertekend maar niet versleuteld — iedereen kan de payload decoderen. Gebruik JWE als je vertrouwelijkheid nodig hebt, of vervoer gevoelige data buiten de token om.