JWT-generator
Opret et signeret JSON Web Token ud fra dine egne JSON-claims. Vælg HS256, HS384 eller HS512 med en delt hemmelighed, RS256 til PS512 med en privat RSA-nøgle, ES256 til ES512 med den tilsvarende EC-nøgle eller EdDSA med en Ed25519-nøgle, angivet som PEM eller JWK. Generatoren kan tilføje iat, exp og et kid-headerfelt, signerer med jose-biblioteket og viser det kompakte token ved siden af dets afkodede header og payload.
Ofte stillede spørgsmål
Hvilke signeringsalgoritmer kan jeg bruge?
Generatoren understøtter HS256, HS384 og HS512 med en delt hemmelighed, RS256, RS384, RS512, PS256, PS384 og PS512 med en privat RSA-nøgle, ES256, ES384 og ES512 med en privat EC-nøgle på P-256, P-384 eller P-521 samt EdDSA med en privat Ed25519-nøgle. Den valgte algoritme skrives i alg-headerfeltet, og typ sættes altid til JWT.
Hvad skal jeg angive som payload?
Indtast et JSON-objekt med dine claims, f.eks. sub, name, iss, aud eller et brugerdefineret felt. Arrays, strenge og andre værdier, der ikke er objekter, afvises, fordi en JWT-payload skal være et JSON-objekt. Rækkefølgen af claims og værdierne bevares præcis, som du skrev dem.
Hvordan læses HMAC-hemmeligheden?
For HS256, HS384 og HS512 bruges hemmeligheden som UTF-8-tekst, efter indledende og afsluttende blanktegn er fjernet. Hvis din hemmelighed er binær, skal du indsætte den som en JWK, f.eks. {"kty": "oct", "k": "..."}, med bytes kodet i base64url; så bruges de afkodede bytes i stedet. PEM-nøgler afvises for HMAC-algoritmer, fordi det er en klassisk fejl at bruge en offentlig nøgle som HMAC-hemmelighed.
Hvor lang bør en HS256-hemmelighed være?
RFC 7518 kræver en nøgle, der mindst er lige så lang som hash-outputtet: altså 32 bytes for HS256, 48 for HS384 og 64 for HS512. Værktøjet signerer med kortere hemmeligheder, så du kan genskabe testtokens, men hemmeligheder til produktion bør være lange, tilfældige værdier, f.eks. fra Password Generator.
Hvilke formater for private nøgler accepteres til RSA, EC og EdDSA?
Indsæt en ukrypteret privat PEM-nøgle i formatet PKCS #8 (BEGIN PRIVATE KEY), PKCS #1 (BEGIN RSA PRIVATE KEY) eller SEC1 (BEGIN EC PRIVATE KEY), eller en privat JWK, der indeholder sit d-felt. Krypterede PEM-filer og private OpenSSH-nøgler læses ikke. Nøglen skal passe til algoritmen, så ES384 kræver en P-384-nøgle, og RSA-nøgler skal være på mindst 2048 bit.
Hvordan sættes iat og exp?
Når indstillingen for udstedelsestidspunkt er slået til, sættes iat til det aktuelle tidspunkt, medmindre payload allerede indeholder en iat-claim. Når udløbstiden er større end 0 sekunder, sættes exp til det aktuelle tidspunkt plus det angivne antal sekunder, og enhver exp i din payload erstattes. Ved en udløbstid på 0 tilføjes ingen exp, og en exp fra din payload bevares.
Hvad bruges kid-feltet til?
Et ikke-tomt nøgle-id skrives i kid-headerfeltet, så verifieringsværktøjer kan vælge den rigtige nøgle fra en JWKS. Hvis du indsætter en JWKS som signeringsnøgle, vælger kid også, hvilken nøgle i sættet der signerer tokenet. JWK Converter og nøglegeneratorerne viser RFC 7638-fingeraftrykket, som er velegnet som kid.
Hvad indeholder resultatet?
Du får det kompakte token, algoritmen, nøgle-id'et, tidspunkterne for udstedelse og udløb i UTC samt de præcise header- og payload-JSON, der blev signeret. Kopiér tokenet fra den første blok. Afkod det senere igen med JWT Decoder, eller kontrollér det med JWT Verifier.
Gemmes mine hemmeligheder eller nøgler?
Nej. Hemmeligheden eller den private nøgle sendes kun med anmodningen om at signere tokenet, bruges én gang i hukommelsen og logges eller gemmes aldrig. Brug alligevel testnøgler til eksperimenter, og indsæt aldrig en privat produktionsnøgle i et webværktøj, medmindre du kontrollerer serveren.
Er der størrelsesgrænser?
Payload må være på op til 65,536 tegn, nøglen op til 65,536 tegn og kid op til 256 tegn. Udløbstiden kan være fra 0 til 315,360,000 sekunder, hvilket svarer til ti år. Længere input afvises med en meddelelse, der angiver feltet.