La prima volta che ho dovuto eseguire il debug di un flusso di autenticazione interrotto su un'API Laravel, ho sprecato un pomeriggio perché non potevo produrre un token di cui mi fidavo Il middleware continuava a restituire 401 e non potevo dire se il bug era nel mio codice di verifica o nel token che lo stavo alimentando Avevo bisogno di un JWT noto-buono con uno specifico sub, una scadenza specifica e un segreto che controllavo, in modo da poter isolare un lato del problema Copiare un token casuale da una risposta di Stack Overflow ha fatto l'opposto dell'aiuto, perché era firmato con un segreto che non avevo.
Questo è il divario che un generatore JWT colma Non è un servizio di firma della produzione È uno strumento da banco per il momento stai costruendo o testando qualcosa che consuma i Web Token JSON e ne hai bisogno di uno valido su richiesta, con le affermazioni esatte e il segreto esatto che scegli Questa guida copre il funzionamento dello strumento, come un JWT viene assemblato e firmato e i casi pratici in cui generare un token a mano ti fa risparmiare tempo reale.
tl; dr: Un generatore JWT trasforma un payload JSON più un segreto in un token firmato Incolla le tue affermazioni, scegli HS256, HS384 o HS512, inserisci il segreto e copia il token Il Generatore JWT firma con il browser Web Crypto API, in modo che il payload e il segreto non lascino mai la macchina Utilizzalo per creare token di test con un noto
sub, una scadenza prestabilita o una scadenza deliberatamente scadutaexpper esercitare i percorsi di errore API's Per leggere un token indietro, associalo al Decoder JWT.
Cos'è un JWT e cosa produce il generatore?
Un token Web JSON è un modo compatto e sicuro per gli URL per rappresentare un insieme di rivendicazioni La struttura è definita dalla RFC 7519, e la forma firmata, che è ciò che quasi tutti intendono con & quot; un JWT, & quot; è una Web Signature JSON come definita dalla RFC 7515 Un token firmato ha tre parti unite da punti: header.payload.signature.
L'intestazione è un piccolo oggetto JSON che nomina l'algoritmo di firma e il tipo di token, qualcosa del genere { "alg": "HS256", "typ": "JWT" }. Il payload è un oggetto JSON di rivendicazioni: chi è il token, quando scade, e qualunque campo personalizzato aggiunge la tua applicazione Sia l'intestazione e il payload sono Base64url-codificato, che è base64 ordinaria con due sostituzioni di caratteri e nessuna imbottitura, esattamente come RFC 7515 specifica La firma è un hash con chiave calcolato sulle prime due parti.
Il generatore li assembla tutti e tre Fornisci il carico utile e il segreto, costruisce l'intestazione, codifica entrambi i segmenti, calcola la firma e li unisce L'output è una stringa che puoi rilasciare direttamente in un Authorization: Bearer intestazione, un dispositivo di prova o a curl comando.
Una cosa vale la pena essere schietto in anticipo: un JWT firmato è codificato, non crittografato Chiunque detenga il token può Base64url-decodificare il payload e leggere ogni rivendicazione in esso La firma non nasconde il contenuto Prova solo che il contenuto non è stato modificato da qualcuno senza la chiave Mai mettere una password, una chiave API, o qualsiasi altra cosa non si mostrerebbe l'utente all'interno di un payload JWT.
Come funziona la firma?
Per la famiglia HMAC, che è ciò con cui questo strumento firma, la firma è HMAC(secret, header + "." + payload). HMAC è una costruzione hash con chiave definita da RFC 2104 e la specifica JWA, RFC 7518, mappa su di essa i tre nomi degli algoritmi JWT: HS256 utilizza HMAC con SHA-256, HS384 utilizza SHA-384 e HS512 utilizza SHA-512.
La proprietà importante è la simmetria Lo stesso segreto crea e verifica la firma Quando il tuo server riceve un token, ricalcola HMAC(secret, header + "." + payload) sopra i primi due segmenti ricevuti e controlla che il risultato sia uguale al segmento di firma Se un singolo byte del payload è stato alterato, l'hash ricalcolato non corrisponderà e la verifica fallisce Questa è l'intera garanzia di integrità.
Perché è simmetrico, il segreto è tutto il gioco Chiunque abbia il segreto può coniare token validi per il tuo sistema, motivo per cui il generatore esegue la firma nel tuo browser attraverso l'API Web Crypto e non trasmette mai il segreto da nessuna parte Puoi confermarlo aprendo il tuo browser's Scheda Rete mentre generi un token: non c'è richiesta Questo conta più di quanto sembri, perché incollare un segreto di firma della produzione live in uno strumento web casuale che telefoni a casa starebbe consegnando le chiavi della tua autenticazione.
RS256 ed ES256, gli algoritmi asimmetrici, funzionano in modo diverso: una chiave privata indica e una chiave pubblica corrispondente verifica Sono la scelta giusta quando molti servizi devono verificare i token ma solo uno dovrebbe essere in grado di emetterli Questo strumento deliberatamente non li offre, perché firmare con loro significa incollare una chiave privata in una pagina web, e questa è un'abitudine che vale la pena non iniziare mai.
Come utilizzare il JWT Generator
Passo 1: Scrivi il payload
Inserisci le tue richieste come oggetto JSON Un esempio minimo è { "sub": "1234567890", "role": "admin" }. la sub claim è l'oggetto, di solito un ID utente È possibile aggiungere tutti i campi personalizzati che l'applicazione legge, come ad esempio role, scope, tenant_id, o email. Lo strumento conserva tutto ciò che metti qui esattamente come scritto.
Passaggio 2: aggiungere le indicazioni temporali
Lasciare emesso e i timbri degli attrezzi iat con l'ora Unix corrente Imposta una scadenza in secondi per aggiungere un exp claim computed as now plus that offset Per un token di accesso di quindici minuti, inserisci 900 Per un token di un'ora, inserisci 3600 Queste sono le affermazioni a cui si riduce la maggior parte dei bug di autenticazione, quindi farli calcolare correttamente, in pochi secondi dall'epoca anziché in millisecondi, rimuove un errore comune.
Passo 3: Scegli l'algoritmo e il segreto
Scegli HS256 a meno che tu non abbia un motivo per usare HS384 o HS512 Inserisci il segreto di firma nel campo Quindi scegli come viene interpretato il segreto: il testo semplice usa i byte UTF-8 di ciò che digiti, mentre base64url ed hex decodificano prima la stringa in byte grezzi Questa scelta conta perché molti sistemi memorizzano il segreto già codificato in base64, e se alimenti la stringa codificata come testo semplice produrrai una firma che non corrisponde.
Passo 4: Copia il token
Il JWT firmato viene visualizzato insieme a un'anteprima decodificata dell'intestazione e del payload in modo da poter confermare ogni reclamo prima di utilizzarlo Copialo e incollalo ovunque ne hai bisogno.
Perché generare un token a mano?
Testare la tua API's percorso felice
Quando scrivi middleware che convalidano i JWT, hai bisogno di un token che il tuo codice dovrebbe accettare Genera uno firmato con lo stesso segreto che usa il tuo verificatore, con un valido exp, e confermare la richiesta restituisce 200 Se non lo fa, il bug è nella vostra logica di verifica, non il token Questo singolo passaggio di isolamento è il motivo per cui raggiungo lo strumento più spesso.
Testare i percorsi di guasto
Una robusta API rifiuta i token giusti per i giusti motivi Genera un token con un exp già in passato per confermare si restituisce l'errore corretto scaduto-token Genera uno con un nbf in futuro per testare il percorso non ancora valido Genera uno firmato con il segreto sbagliato per confermare le tue esecuzioni di controllo della firma Questi casi negativi sono quelli che vengono spediti non testati e un generatore li rende un lavoro di trenta secondi.
Riproduzione di un bug da un utente specifico
Il supporto segnala un problema che si verifica solo per gli account con un ruolo particolare Genera un token con quell'esatto role reclamo e l'utente interessato's sub, e puoi riprodurre la richiesta localmente senza toccare i dati di produzione o chiedere all'utente il suo token reale del portatore, cosa che comunque non dovresti mai fare.
Seminare lo sviluppo locale
I nuovi sviluppatori di un team hanno bisogno di un token funzionante per colpire gli endpoint protetti mentre l'auth front-end è ancora in fase di costruzione Un token generato firmato con il segreto di sviluppo locale li sblocca immediatamente.
HS256 vs HS384 vs HS512: quale dovresti usare?
| algoritmo | Hash | Dimensione firma | Lunghezza minima della chiave | Quando utilizzare |
|---|---|---|---|---|
| HS256 | SHA-256 | 32 byte | 32 byte | L'impostazione predefinita Veloce, ampiamente supportata, sicura per quasi tutti gli usi |
| HS384 | SHA-384 | 48 byte | 48 byte | Quando una politica o uno standard richiede SHA-384 |
| HS512 | SHA-512 | 64 byte | 64 byte | Contesti ad alta sicurezza, o quando già si standardizza su SHA-512 |
La risposta pratica è HS256 a meno che qualcosa di esterno non richieda diversamente RFC 7518 richiede che la chiave sia lunga almeno quanto l'uscita hash, quindi 32 byte per HS256, 48 per HS384 e 64 per HS512 Il generatore avvisa quando il tuo segreto decodificato è più corto del minimo, perché una chiave corta indebolisce la firma indipendentemente dal nome dell'algoritmo Un algoritmo più lungo e con numeri più alti non fissa un segreto debole; un segreto casuale di lunghezza propria è ciò che conta.
Errori comuni e come evitarli
Quello più frequente è un disadattamento segreto causato dalla codifica Il tuo framework memorizza il segreto come base64, incolli la stringa base64 come testo normale e ora i byte chiave differiscono da quelli utilizzati dal verificatore Le firme non corrispondono mai e insegui un bug fantasma Risolvilo scegliendo la codifica segreta corretta nello strumento in modo che i byte della chiave grezza siano identici su entrambi i lati.
Il secondo è confusionare secondi e millisecondi Le affermazioni di tempo registrate in RFC 7519 sono tutte misurate in secondi dall'epoca Unix JavaScript' s Date.now() restituisce millisecondi Se calcoli exp te stesso e dimentica di dividere per 1000, il tuo token sembra scadere tra cinquantamila anni, cosa che alcuni severi verificatori rifiuteranno Lasciare che il generatore calcoli le affermazioni lo evita del tutto.
Il terzo è trattare il carico utile come privato Non lo è Se sei tentato di memorizzare un segreto in un reclamo, fermati Chiunque abbia il token può leggerlo Memorizza solo ciò che ti senti a tuo agio con il token holder che vede, e mantieni dati genuinamente segreti sul server.
Dove i JWT si affiancano ad altri strumenti
Una volta generato un token, il passo successivo naturale è rileggerlo. IL Decoder JWT divide qualsiasi token nella sua intestazione e nel carico utile e contrassegna uno scaduto exp, che è come confermi che il generatore ha prodotto ciò che intendevi Se stai generando anche segreti, il Generatore di hash calcola gli hash SHA lato client e Generatore di password produce il tipo di lunga stringa casuale che rende un buon segreto HMAC in primo luogo Se si vuole capire il Base64url passo a mano, il Base64 Encoder/Decodificatore mostra la stessa trasformazione reversibile che trasforma l'intestazione e il payload nella loro forma codificata E quando hai bisogno di un identificatore casuale per cadere in un sub oppure jti rivendicazione, il Generatore di UUID te ne dà uno nel formato giusto.
Per un quadro più ampio del motivo per cui gli strumenti basati su browser mantengono materiale sensibile lontano dai server di terze parti, il Privacy dei dati negli strumenti online guida spiega il modello lato client, e il Toolkit per sviluppatori web arrotonda le utilità che si abbinano bene al lavoro dei token.
Come fa un server a verificare il token che generi?
Aiuta a sapere cosa succede dall'altra parte, perché spiega perché il segreto e le affermazioni devono essere esattamente giusti Quando la tua API riceve un token, una libreria come jsonwebtoken, jose o PyJWT fa tre cose in ordine Divide il token sui punti e Base64url-decodifica l'intestazione per leggere il alg. Ricomputa la firma header.payload utilizzando il segreto configurato e lo confronta, byte per byte, con il segmento della firma E controlla le affermazioni registrate: è exp in passato, è nbf in futuro, lo fa iss e aud abbina ciò che l'API si aspetta.
Ognuno di questi controlli si associa a qualcosa che il generatore ti consente di controllare. Se la verifica fallisce sulla firma, il segreto o la sua codifica differiscono tra i due lati. Se fallisce exp, il token è scaduto, che potresti aver causato apposta per testare quel percorso Se fallisce alg, hai generato un token con un algoritmo che il verificatore non è configurato per accettare, che è di per sé una cosa utile da scoprire Generare token con variazioni deliberate è il modo in cui mappi esattamente quale controllo impone la tua API e quale salta silenziosamente.
Una parola sul alg intestazione nello specifico. RFC 7515 definisce none come algoritmo valido per un token non firmato e le prime librerie si fiderebbero di un token che lo affermava alg: none e salta completamente la verifica Questa è la classica vulnerabilità JWT Le librerie moderne la rifiutano per impostazione predefinita, ma il generatore offre la none opzione precisamente in modo da poter sparare un token non firmato alla tua API e confermare che dice di no. Se la tua API ne accetta mai uno, hai trovato un bug grave.
Come dovresti gestire i segreti e lo stoccaggio dei token?
Il segreto con cui firmi merita la stessa cura di una password di database Un buon segreto HMAC è una stringa lunga e casuale, non una frase memorabile, perché la sicurezza HMAC dipende dal fatto che la chiave sia imperdonabile, generandone una con uno strumento password e memorizzandola nella configurazione del tuo ambiente, mai nel controllo sorgente, è la linea di base Quando la ruoti, ricorda che ogni token firmato con il vecchio segreto diventa invalido nel momento in cui il verificatore cambia, motivo per cui i sistemi di produzione solitamente supportano più di un segreto valido durante una finestra di rotazione.
Sul lato client, dove memorizzi il token finito conta tanto quanto come lo firmi Un token in localStorage è leggibile da qualsiasi JavaScript sulla pagina, quindi un singolo difetto di scripting cross-site consegna a un utente malintenzionato una credenziale valida. UN httpOnly, Secure, SameSite il cookie è invisibile agli script, il che chiude quel percorso al costo di aver bisogno della protezione CSRF. Il modello comune è un token di accesso di breve durata mantenuto in memoria e un token di aggiornamento di più lunga durata in un httpOnly cookie Nulla di tutto ciò cambia il modo in cui si genera un token, ma è il contesto che rende sicuro l'utilizzo di un token generato piuttosto che una responsabilità.
FAQ
Come si genera un JWT?
Incolla le tue affermazioni come oggetto JSON, scegli un algoritmo di firma come HS256 e inserisci il segreto Lo strumento base64url-codifica l'intestazione e il payload, calcola la firma HMAC e restituisce il token finito affinché tu possa copiare Tutto viene eseguito nel tuo browser.
Quali algoritmi di firma sono supportati?
HS256, HS384 e HS512, la famiglia HMAC, oltre a un'opzione & quot; non firmate & quot; none" per il test RS256 ed ES256 non sono deliberatamente offerti perché firmano con una chiave privata e incollare una chiave privata in una pagina web è un rischio per la sicurezza che è meglio evitare.
Il mio segreto viene inviato a un server?
No. La firma viene eseguita interamente nel browser tramite l'API Web Crypto, quindi il segreto e il payload non lasciano mai il dispositivo È possibile confermarlo nella scheda Rete DevTools e lo strumento continua a funzionare offline una volta caricato.
Come faccio a impostare la scadenza del token?
Inserisci una scadenza in pochi secondi e lo strumento aggiunge un exp rivendicazione pari al tempo corrente più che molti secondi Per un token di quindici minuti inserire 900 Lasciare il campo vuoto da omettere exp interamente.
Perché il segreto dovrebbe essere di almeno 32 byte?
RFC 7518 richiede una chiave HMAC almeno fino a quando l'uscita hash, che è di 32 byte per HS256, 48 per HS384 e 64 per HS512 Un segreto più breve indebolisce la firma, quindi lo strumento avverte quando il segreto decodificato è troppo breve.
Posso creare un token non firmato?
Sì. Selezionare alg none e lo strumento produce un token header.payload. con una firma vuota Questo è solo per testare il modo in cui la tua API gestisce i token non firmati; la maggior parte delle librerie rifiuta alg: nessuno per impostazione predefinita, e dovresti farlo anche tu.
Un JWT generato è crittografato?
No. Un JWT firmato è codificato, non crittografato: chiunque può base64url-decodificare l'intestazione e il payload e leggere ogni reclamo La firma dimostra solo che il contenuto non è stato modificato Non mettere mai password o segreti all'interno del payload.
