Strumenti per sviluppatori · Decodificatore JWT
Base64 vs Base64url: perché un JWT fallisce in un decoder Base64 standard
· Come funziona
jwt base64 codifica
Incolla un segmento JWT in un normale decoder base64 e potrebbe lamentarsi di caratteri o riempimento. Questo post spiega i mandati della variante base64url JWS e come effettuare la conversione tra i due.
Carattere non valido, riempimento errato: gli errori che compaiono quando base64 incontra base64url
Un messaggio di "carattere non valido" o di "imbottitura errata" spesso significa che un segmento JWT è stato assegnato a un decodificatore che si aspetta Base64 ordinario. Il token potrebbe essere copiato correttamente. La sua rappresentazione segue le convenzioni base64url, mentre l'utilità ricevente accetta un alfabeto correlato ma non identico o insiste su un riempimento esplicito.
ToolAcre evita questa mancata corrispondenza tra l'intestazione e il payload. Il suo decodificatore di byte rimuove gli spazi bianchi, traduce i simboli URL-safe, ripristina il riempimento omesso quando la lunghezza lo consente, quindi converte i byte come UTF-8 rigoroso. Il fallimento in qualsiasi fase diventa un errore INVALID_JWT anziché un'eccezione del browser non elaborata.
Due alfabeti: più e barra rispetto a trattino e carattere di sottolineatura e perché gli URL hanno imposto il cambiamento
Base64 standard utilizza più e barra per le sue due posizioni finali dell'alfabeto. Base64url assegna il trattino e il carattere di sottolineatura alle stesse posizioni. I valori a sei bit sottostanti non cambiano, quindi la traduzione di `-` in `+` e `_` in `/` preserva ogni byte decodificato; cambia solo l'ortografia sicura per il trasporto.
Queste sostituzioni sono importanti nei canali in cui più o barra hanno già una sintassi. Un'ortografia sicura URL riduce l'interpretazione accidentale tramite l'elaborazione di moduli o percorsi. Non aggiunge segretezza, integrità o autenticità. Chiunque riceva un segmento può invertire le sostituzioni e recuperare gli stessi byte senza chiave crittografica.
Padding: perché JWS rimuove i segni di uguale e come ripristinarli per un decodificatore rigoroso
ToolAcre accetta il riempimento omesso. Dopo la normalizzazione dell'alfabeto, esamina la lunghezza del segmento modulo quattro. Per il resto di due sono necessari due segni di uguale, mentre per il resto di tre è necessario uno. Il resto di uno è impossibile per un valore Base64 completo e viene rifiutato come stringa troncata anziché indovinata nella forma.
Il ripristino del riempimento è un'inquadratura meccanica, non una riparazione simbolica. L'aggiunta di segni di uguale non può ripristinare i caratteri persi durante la copia e la decodifica dei byte riuscita non mostra che i byte provenivano da un emittente. L'implementazione ricostruisce semplicemente la lunghezza canonica richiesta dal decodificatore del browser prima di chiamare `atob`.
Decodificare l'intero token in una volta: l'errore di non dividere prima i punti
Un token firmato compatto deve essere diviso sui suoi punti prima che qualsiasi segmento venga decodificato. Il passaggio di `header.payload.signature` a una funzione Base64 introduce punti che appartengono alla serializzazione JWT, non all'alfabeto Base64. ToolAcre richiede esattamente tre segmenti per questo input a forma di JWS e segnala il conteggio osservato quando tale struttura è assente.
Il caso in cinque parti riceve un messaggio JWE separato perché la serializzazione compatta crittografata non è lo stesso oggetto. Due o quattro parti suggeriscono invece un troncamento o un input errato. Questo controllo strutturale viene prima dell'interpretazione JSON, mantenendo un errore di copia distinto dal testo codificato non valido o da JSON non valido.
Esempio funzionante: conversione di un segmento da base64url a base64, riempimento e decodifica in JSON
Per una conversione riuscita, prendi `eyJhbGciOiJIUzI1NiJ9`. Non contiene caratteri alfabetici che differiscono tra le varianti, ma il riempimento mancante illustra comunque la pipeline. La sua lunghezza permette il ripristino dell'imbottitura; la decodifica produce UTF-8 byte per `{"alg":"HS256"}` e l'analisi JSON produce un oggetto con una proprietà `alg`.
Un segmento contenente un trattino o un carattere di sottolineatura segue la stessa sequenza con prima la sostituzione dei due simboli. ToolAcre esegue queste operazioni all'interno di `base64ToBytes`, quindi `decodeSegment` analizza il testo risultante. L'algoritmo visualizzato è qualunque cosa dichiari l'intestazione non verificata; non è selezionato come criterio di verifica.
Unicode nelle attestazioni: perché i byte decodificati devono essere letti come UTF-8 per visualizzare correttamente i nomi
Le rivendicazioni possono contenere accenti, caratteri CJK o emoji. Base64 opera su byte, quindi trattare ciascun byte decodificato come un carattere indipendente corrompe il testo multibyte. Il percorso corretto è simboli codificati in byte, quindi un decodificatore UTF-8. ToolAcre costruisce `TextDecoder` con modalità fatale quindi non valido UTF-8 fallisce rumorosamente.
I test coprono un payload contenente `Zoë 世界 🙂` e prevedono la stringa esatta dopo la decodifica. Questo risultato dimostra che la pipeline byte-to-text ha preservato questo valore di test. Non dice ancora nulla sull'esistenza della persona nominata dal payload, se l'emittente ha approvato la richiesta o se il token è stato alterato.
Ciò che questo non copre è il segmento della firma, che viene decodificato in byte anziché in testo e necessita di una chiave per significare qualsiasi cosa
Il segmento della firma è esterno al percorso JSON. ToolAcre mantiene la sua forma codificata originale e cerca solo di misurare la lunghezza dei byte decodificati. Firma non valida Base64 produce un avviso ma non impedisce l'ispezione dell'intestazione e del carico utile; un terzo segmento vuoto produce un avviso diverso che non sono presenti byte di firma.
Nessuno dei due risultati è un risultato di verifica. Una valida convalida della firma necessita di materiale chiave attendibile, di un algoritmo consentito scelto indipendentemente dall’input controllato dall’aggressore e di controlli dell’applicazione. Un conteggio dei byte è utile quando si diagnostica la forma, ma zero o trentadue byte misurati non possono autorizzare una richiesta o stabilire un emittente.
Conclusione: usa un decodificatore che parli base64url: il decodificatore ToolAcre JWT gestisce l'alfabeto e il riempimento per l'intestazione e il payload
Utilizzare un decodificatore che comprenda base64url quando il lavoro immediato sta ispezionando JSON. ToolAcre gestisce l'alfabeto, il riempimento omesso, il rigoroso UTF-8 e il solo oggetto JSON per i primi due segmenti. Rifiuta inoltre lunghezze impossibili e racchiude gli errori di analisi nei messaggi che identificano se l'intestazione o il payload hanno avuto esito negativo.
Fermati a quel confine. Una decodifica pulita significa che la stringa aveva byte recuperabili e oggetti JSON adatti. Ciò non significa che le sue affermazioni siano affidabili, autenticate, autorizzate o non modificate. Solo un verificatore configurato separatamente può rispondere a queste domande e questo strumento del browser non espone deliberatamente alcuna operazione di verifica.