De eerste keer dat ik een kapotte auth flow moest debuggen op een Laravel API, verspilde ik een middag omdat ik geen token kon produceren dat ik vertrouwde De middleware bleef 401 retourneren, en ik kon niet zeggen of de bug in mijn verificatiecode zat of in het token dat ik hem voerde Ik had een bekend-goed JWT nodig met een specifieke sub, een specifieke vervaldatum, en een geheim dat ik beheerste, zodat ik één kant van het probleem kon isoleren Het kopiëren van een willekeurig token van een Stack Overflow antwoord deed het tegenovergestelde van hulp, omdat het was ondertekend met een geheim dat ik niet had.
Dat is het gat dat een JWT generator opvult Het is geen productie signing service Het is een bench tool voor het moment dat je iets bouwt of test dat JSON Web Tokens verbruikt en je hebt een geldige nodig op aanvraag, met de exacte claims en het exacte geheim dat je kiest Deze gids behandelt hoe de tool werkt, hoe een JWT wordt samengesteld en ondertekend, en de praktische gevallen waarin het genereren van een token met de hand je realtime bespaart.
tl;dr: Een JWT generator maakt van een JSON payload plus een geheim een gesigneerd token Plak je claims, kies HS256, HS384, of HS512, voer het geheim in, en kopieer het token De JWT Generator tekent met de browser Web Crypto API, zodat de payload en het geheim nooit van uw machine weggaan Gebruik het om testtokens te maken met een bekende
sub, een vastgestelde vervaldatum, of een opzettelijk verlopenexpom uw API' s foutpaden uit te oefenen Om een token terug te lezen, koppelt u het aan de JWT-decoder.
Wat is een JWT en wat produceert de generator?
Een JSON Web Token is een compacte, URL-veilige manier om een reeks claims weer te geven De structuur wordt gedefinieerd door RFC 7519, en het ondertekende formulier, wat bijna iedereen bedoelt met & quot; een JWT, & quot; is een JSON Web Signature zoals gedefinieerd door RFC 7515 Een ondertekend token heeft drie delen die met elkaar zijn verbonden door stippen: header.payload.signature.
De header is een klein JSON-object dat het ondertekeningsalgoritme en het tokentype een naam geeft, zoiets als { "alg": "HS256", "typ": "JWT" }. De payload is een JSON object van claims: over wie het token gaat, wanneer het verloopt, en welke aangepaste velden uw applicatie ook toevoegt Zowel de header als de payload zijn Base64url-gecodeerd, wat gewone base64 is met twee tekenvervangingen en geen opvulling, precies zoals RFC 7515 specificeert De handtekening is een ingetoetste hash die over de eerste twee delen is berekend.
De generator stelt ze alle drie samen Je levert de payload en het geheim, het bouwt de header, codeert beide segmenten, berekent de handtekening, en voegt ze samen De output is een string die je direct in een Authorization: Bearer header, een testopstelling of een curl command.
Eén ding dat de moeite waard is om vooraf bot over te zijn: een ondertekende JWT is gecodeerd, niet gecodeerd Iedereen die het token vasthoudt, kan de payload van Base64url decoderen en elke claim erin lezen De handtekening verbergt de inhoud niet. Het bewijst alleen dat de inhoud niet is gewijzigd door iemand zonder de sleutel. Plaats nooit een wachtwoord, een API-sleutel of iets anders dat u de gebruiker niet in een JWT-payload wilt laten zien.
Hoe werkt de ondertekening?
Voor de HMAC-familie, waar dit gereedschap mee tekent, is de handtekening HMAC(secret, header + "." + payload). HMAC is een hashconstructie met sleutel, gedefinieerd door RFC 2104, en de JWA-specificatie, RFC 7518, wijst de drie JWT-algoritmenamen erop toe: HS256 gebruikt HMAC met SHA-256, HS384 gebruikt SHA-384 en HS512 gebruikt SHA-512.
De belangrijke eigenschap is symmetrie Hetzelfde geheim maakt en verifieert de handtekening, wanneer uw server een token ontvangt, wordt deze opnieuw berekend HMAC(secret, header + "." + payload) over de ontvangen eerste twee segmenten en controleert of het resultaat gelijk is aan het handtekeningsegment Als een enkele byte van de payload is gewijzigd, komt de opnieuw berekende hash niet overeen en mislukt de verificatie. Dat is de volledige integriteitsgarantie.
Omdat het symmetrisch is, is het geheim het hele spel Iedereen met het geheim kan geldige tokens voor je systeem slaan, daarom voert de generator de ondertekening in je browser uit via de Web Crypto API en verzendt het geheim nooit ergens U kunt dit bevestigen door uw browser te openen' s Netwerk tabblad terwijl u een token genereert: er is geen verzoek Dit is belangrijker dan het klinkt, omdat het plakken van een live productie signing geheim in een willekeurige web tool die naar huis belt zou zijn het overhandigen van de sleutels tot uw authenticatie.
RS256 en ES256, de asymmetrische algoritmes, werken anders: een private key signs en een matching public key verifieert Dat zijn de juiste keuze wanneer veel services tokens moeten verifiëren maar er maar één in staat moet zijn om ze uit te geven Deze tool biedt ze bewust niet aan, omdat het ondertekenen met hen betekent dat je een private key in een webpagina plakt, en dat is een gewoonte die de moeite waard is om nooit te beginnen.
Hoe de JWT Generator te gebruiken
Stap 1: Schrijf de payload
Vul uw claims in als JSON object Een minimaal voorbeeld is { "sub": "1234567890", "role": "admin" }. de sub claim is het onderwerp, meestal een gebruikers-ID U kunt alle aangepaste velden toevoegen die uw applicatie leest, zoals role, scope, tenant_id, of email. De tool houdt wat je hier plaatst precies zoals geschreven.
Stap 2: Voeg de tijdclaims toe
Laat uitgegeven op en de gereedschapsstempels iat met de huidige Unix tijd Stel een vervaldatum in seconden in om een exp claim berekend als nu plus die offset Voor een toegangstoken van vijftien minuten voert u 900 in. Voor een token van één uur voert u 3600 in. Dit zijn de claims waar de meeste authenticatiefouten op neerkomen, dus als u ze correct laat berekenen, in seconden sinds het tijdperk in plaats van milliseconden, wordt een veelgemaakte fout verwijderd.
Stap 3: Kies het algoritme en geheim
Kies HS256 tenzij je een reden hebt om HS384 of HS512 te gebruiken Voer het ondertekeningsgeheim in het veld in Kies vervolgens hoe het geheim wordt geïnterpreteerd: platte tekst gebruikt de UTF-8 bytes van wat je typt, terwijl base64url en hex de tekenreeks eerst decoderen in ruwe bytes Deze keuze is belangrijk omdat veel systemen het geheim opslaan dat al base64-gecodeerd is, en als je de gecodeerde tekenreeks als platte tekst invoegt, produceer je een handtekening die niet overeenkomt.
Stap 4: Kopieer het token
De ondertekende JWT verschijnt samen met een gedecodeerde preview van de header en payload, zodat u elke claim kunt bevestigen voordat u deze gebruikt Kopieer het en plak het waar u het nodig hebt.
Waarom een token met de hand genereren?
Het testen van uw API's gelukkige pad
Wanneer u middleware schrijft die JWT's valideert, heeft u een token nodig dat uw code zou moeten accepteren Genereer er een ondertekend met hetzelfde geheim dat uw verificateur gebruikt, met een geldig exp, en bevestig het verzoek retourneert 200. Als dit niet het geval is, zit de bug in uw verificatielogica, niet in het token. Deze enkele isolatiestap is de reden waarom ik het vaakst naar het gereedschap grijp.
Testen van de faalpaden
Een robuuste API wijst de juiste tokens om de juiste redenen af Genereer een token met een exp al in het verleden om te bevestigen dat u de juiste fout met verlopen token retourneert Genereer er een met een nbf in de toekomst om het nog niet-geldige pad te testen Genereer er een ondertekend met het verkeerde geheim om uw handtekeningcontrole te bevestigen Deze negatieve gevallen worden niet getest en een generator maakt ze tot een taak van dertig seconden.
Een bug van een specifieke gebruiker reproduceren
Support rapporteert een probleem dat alleen gebeurt voor accounts met een bepaalde rol Genereer een token met precies dat role claim en de getroffen gebruiker's sub, en u kunt het verzoek lokaal reproduceren zonder productiegegevens aan te raken of de gebruiker om zijn echte dragertoken te vragen, wat u toch nooit zou moeten doen.
Lokale ontwikkeling nastreven
Nieuwe ontwikkelaars in een team hebben een werkend token nodig om beschermde eindpunten te raken terwijl de front-end auth nog wordt gebouwd Een gegenereerd token ondertekend met het lokale ontwikkelingsgeheim deblokkeert ze onmiddellijk.
HS256 versus HS384 versus HS512: welke moet u gebruiken?
| algoritme | Hash | Handtekening grootte | Minimale sleutellengte | Wanneer te gebruiken? |
|---|---|---|---|---|
| HS256 | SHA-256 | 32 bytes | 32 bytes | De standaard Snel, breed ondersteund, veilig voor bijna alle gebruik |
| HS384 | SHA-384 | 48 bytes | 48 bytes | Wanneer een beleid of standaard SHA-384 vereist |
| HS512 | SHA-512 | 64 bytes | 64 bytes | Hoogbeveiligde contexten, of wanneer u al standaardiseert op SHA-512 |
Het praktische antwoord is HS256 tenzij iets externs anders vereist RFC 7518 vereist dat de sleutel minstens zo lang is als de hash-uitvoer, dus 32 bytes voor HS256, 48 voor HS384 en 64 voor HS512. De generator waarschuwt wanneer uw gedecodeerde geheim korter is dan het minimum, omdat een korte sleutel de handtekening verzwakt, ongeacht de naam van het algoritme. Een langer algoritme met een hoger nummer repareert geen zwak geheim; een willekeurig geheim van de juiste lengte is waar het om gaat.
Veelgemaakte fouten en hoe u deze kunt vermijden
De meest voorkomende is een geheime mismatch veroorzaakt door codering Uw framework slaat het geheim op als basis64, u plakt de basis64-tekenreeks als platte tekst, en nu verschillen de sleutelbytes van wat uw verificateur gebruikt De handtekeningen komen nooit overeen en u achtervolgt een fantoombug Fix it door de juiste geheime codering in het gereedschap te kiezen, zodat de ruwe sleutelbytes aan beide kanten identiek zijn.
De tweede is verwarrende seconden en milliseconden De geregistreerde tijdclaims in RFC 7519 worden allemaal gemeten in seconden sinds het Unix-tijdperk JavaScript' s Date.now() retourneert milliseconden. Als u berekent exp jezelf en vergeet te delen door 1000, je token lijkt te verlopen vijftigduizend jaar vanaf nu, die sommige strikte verificateurs zullen verwerpen Laat de generator de claims berekenen vermijdt dit volledig.
De derde is het behandelen van de payload als privé Het is niet Als je in de verleiding komt om een geheim op te slaan in een claim, stop dan Iedereen met het token kan het lezen Bewaar alleen wat je prettig vindt als de tokenhouder ziet, en bewaar echt geheime gegevens op de server.
Waar JWT's naast andere tools passen
Als je een token hebt gegenereerd, is de natuurlijke volgende stap om het terug te lezen De JWT-decoder splitst elk token in de header en payload en markeert een verlopen exp, dat is hoe u bevestigt dat de generator produceerde wat u bedoelde. Als u ook geheimen genereert, is de Hash-generator berekent SHA-hashes client-side, en de Wachtwoordgenerator produceert het soort lange willekeurige string die een goede HMAC geheim maakt in de eerste plaats Als je de Base64url stap voor hand wilt begrijpen, de Base64 Encoder/decoder toont dezelfde omkeerbare transformatie die de header en payload in hun gecodeerde vorm verandert En wanneer u een willekeurige identificatie nodig heeft om in een sub of jti claim, de UUID-generator geeft je er een in het juiste formaat.
Voor het bredere beeld van waarom browsergebaseerde tools gevoelig materiaal van servers van derden houden, is de Gegevensprivacy in online tools gids legt het model aan de clientzijde uit, en de Webontwikkelaar Toolkit rondt de hulpprogramma's af die goed aansluiten bij tokenwerk.
Hoe verifieert een server het token dat u genereert?
Het helpt om te weten wat er aan de andere kant gebeurt, omdat het verklaart waarom het geheim en de claims precies goed moeten zijn Wanneer uw API een token ontvangt, doet een bibliotheek zoals jsonwebtoken, jose of PyJWT drie dingen op volgorde Het splitst het token op de punten en Base64url-decodeert de header om de te lezen alg. Het berekent de handtekening opnieuw header.payload het geconfigureerde geheim gebruiken en het, byte voor byte, vergelijken met het handtekeningsegment En het controleert de geregistreerde claims: is exp in het verleden is nbf in de toekomst wel iss en aud overeenkomen met wat de API verwacht.
Elk van die controles wordt toegewezen aan iets dat de generator u laat controleren. Als de verificatie van de handtekening mislukt, verschilt het geheim of de codering ervan tussen de twee zijden. Als deze mislukt exp, het token is verlopen, wat u mogelijk met opzet hebt veroorzaakt om dat pad te testen Als het mislukt alg, u hebt een token gegenereerd met een algoritme waarvoor de verificateur niet is geconfigureerd om te accepteren, wat op zichzelf al handig is om te ontdekken Het genereren van tokens met opzettelijke variaties is hoe u precies in kaart brengt welke controle uw API afdwingt en welke deze in stilte overslaat.
Een woord over de alg kop specifiek. RFC 7515 definieert none als een geldig algoritme voor een niet-ondertekend token, vertrouwden vroege bibliotheken een token dat beweerde alg: none en sla de verificatie helemaal over Dat is de klassieke JWT kwetsbaarheid Moderne bibliotheken wijzen het standaard af, maar de generator biedt de none optie precies zodat u een niet-ondertekend token op uw API kunt afvuren en kunt bevestigen dat er nee op staat Als uw API er ooit een accepteert, heeft u een ernstige bug gevonden.
Hoe moet je omgaan met geheimen en tokenopslag?
Het geheim waarmee u tekent verdient dezelfde zorg als een database wachtwoord Een goed HMAC geheim is een lange, willekeurige string, geen memorabele zin, omdat HMAC beveiliging afhankelijk is van de sleutel is onraadbaar Genereren met een wachtwoord tool en opslaan in uw omgeving configuratie, nooit in broncontrole, is de basislijn Wanneer u het roteert, onthoud dan dat elk token ondertekend met het oude geheim ongeldig wordt op het moment dat de verificateur schakelt, dat is de reden waarom productiesystemen meestal ondersteunen meer dan één geldig geheim tijdens een rotatie venster.
Aan de clientzijde, waar u het afgewerkte token opslaat, doet er net zoveel toe als hoe u het ondertekent. Een token in localStorage is leesbaar voor elk JavaScript op de pagina, dus een enkele cross-site scriptingfout levert een aanvaller een geldige inloggegevens op. Een httpOnly, Secure, SameSite cookie is onzichtbaar voor scripts, waardoor dat pad wordt afgesloten ten koste van de noodzaak van CSRF-bescherming. Het gebruikelijke patroon is een kortstondig toegangstoken dat in het geheugen wordt bewaard en een langerlevend vernieuwingstoken in een httpOnly cookie. Niets van dit alles verandert de manier waarop u een token genereert, maar het is de context die een gegenereerd token veilig maakt om te gebruiken in plaats van een verplichting.
FAQ
Hoe genereer ik een JWT?
Plak uw claims als een JSON-object, kies een ondertekeningsalgoritme zoals HS256 en voer het geheim in De tool base64url codeert de header en payload, berekent de HMAC-handtekening en retourneert het voltooide token zodat u deze kunt kopiëren. Alles draait in uw browser.
Welke ondertekeningsalgoritmen worden ondersteund?
HS256, HS384 en HS512, de HMAC-familie, plus een niet-ondertekende & quot; geen" optie voor testen. RS256 en ES256 worden opzettelijk niet aangeboden omdat ze met een privésleutel ondertekenen, en het plakken van een privésleutel op een webpagina is een veiligheidsrisico dat het beste kan worden vermeden.
Wordt mijn geheim naar een server gestuurd?
Nee De ondertekening loopt volledig in uw browser via de Web Crypto API, dus het geheim en de payload verlaten uw apparaat nooit U kunt dit bevestigen in het tabblad DevTools Network, en de tool blijft offline werken zodra deze is geladen.
Hoe stel ik het token in om te verlopen?
Voer een vervaldatum in seconden in en het gereedschap voegt een exp claim gelijk aan de huidige tijd plus zoveel seconden Voor een vijftien minuten token voer je 900. veld leeg om weg te laten exp geheel.
Waarom zou het geheim minstens 32 bytes moeten zijn?
RFC 7518 vereist een HMAC-sleutel minstens zo lang als de hash-uitvoer, die 32 bytes is voor HS256, 48 voor HS384 en 64 voor HS512. Een korter geheim verzwakt de handtekening, dus het gereedschap waarschuwt wanneer het gedecodeerde geheim te kort is.
Kan ik een niet-ondertekend token maken?
Ja. selecteer alg geen en de tool produceert een header.payload. token met een lege handtekening Dit is alleen voor het testen van hoe uw API omgaat met niet-ondertekende tokens; de meeste bibliotheken weigeren standaard alg: geen, en dat zou u ook moeten doen.
Is een gegenereerde JWT gecodeerd?
Nee Een ondertekende JWT is gecodeerd, niet versleuteld: iedereen kan de header en payload baseren64url-decoderen en elke claim lezen De handtekening bewijst alleen dat de inhoud niet is gewijzigd Zet nooit wachtwoorden of geheimen in de payload.
