Strumenti per sviluppatori · Decodificatore JWT
Decodifica o verifica: cosa dimostra una firma JWT e perché i decoder la saltano
· Come funziona
jwt sicurezza crittografia
La decodifica non necessita di chiave; la verifica richiede quella giusta. Questo post spiega cosa copre la firma, come differiscono HMAC e la verifica asimmetrica e perché uno strumento di sola decodifica è onesto nel non provare nulla.
È stato decodificato correttamente, quindi deve essere valido: il presupposto che porta ad accettare token contraffatti
Un token può essere decodificato perfettamente dopo che un utente malintenzionato ha scritto un nuovo payload e ha allegato un testo arbitrario come terzo segmento. L'analisi Base64url e JSON sono trasformazioni pubbliche; nessuno dei due controlla chi ha assemblato la stringa. "Le affermazioni apparse sullo schermo" non costituiscono quindi la prova che l'emittente le abbia create o approvate.
ToolAcre rafforza questo confine in diversi punti. Il risultato riporta sempre `signatureVerified: false`, l'interfaccia utente ripete un avviso di affermazioni non verificate accanto all'output e i test affermano che non esiste una superficie `valid` o `verify`. Questa è onestà deliberata, non una caratteristica di comodità mancante.
Cosa copre la firma: i byte esatti dell'intestazione codificata e del payload, uniti da un punto
Per il formato compatto JWS, l'input della firma è il segmento di intestazione protetta codificato, un punto letterale e il segmento di payload codificato. La verifica riguarda quegli esatti byte codificati, non appena stampati JSON. Il riordino delle proprietà o la modifica degli spazi bianchi può creare byte diversi anche quando un essere umano vede oggetti equivalenti.
Il terzo segmento porta la firma codificata o i byte MAC prodotti su quell'input. ToolAcre preserva il segmento non elaborato e può riportarne la lunghezza in byte, ma non esegue mai un controllo crittografico. La misurazione della forma dei dati non può stabilire se la chiave prevista l'ha creata o se i primi due segmenti sono rimasti invariati.
HMAC rispetto a asimmetrico: un segreto condiviso che chiunque possa verificare può anche falsificare, rispetto a una chiave pubblica che può solo verificare
Con HMAC, un segreto condiviso supporta sia la creazione che il controllo di MAC. Una parte in grado di verificare con quel segreto può anche coniare un altro token, quindi la distribuzione del segreto definisce il confine di fiducia. Le note di ToolAcre rendono esplicita questa conseguenza per le etichette riconosciute dell'algoritmo HS.
Le firme asimmetriche separano la funzionalità di firma privata dal materiale di verifica pubblico. Possedere una chiave pubblica può supportare il controllo senza concedere l'autorità di firma. Questa distinzione non rende affidabile un'etichetta asimmetrica dichiarata dall'intestazione: il verificatore deve già sapere quale algoritmo e quale chiave dell'emittente sono accettabili.
Da dove proviene la chiave: configurazione per segreti condivisi, un endpoint JWKS per chiavi pubbliche, abbinato per bambino
I segreti condivisi dovrebbero provenire dalla configurazione del servizio protetto, non dal testo del token. Le chiavi di verifica pubbliche possono provenire da una relazione con un emittente attendibile e da un set di chiavi controllato. Un `kid` può aiutare a selezionare all'interno di tale set, ma non deve trasformare il contenuto arbitrario di un'intestazione non attendibile in una ricerca di file, database o rete.
ToolAcre non ha alcuna configurazione dell'emittente e non richiede alcuna chiave, quindi sarebbe impossibile eseguire la verifica in modo responsabile lì. Una pagina Web generica non può dedurre di quale organizzazione ti fidi, quale pubblico servi o quali algoritmi consentiti dalla tua applicazione. Si tratta di input di criteri applicativi, non di proprietà rilevabili tramite decodifica.
Perché la decodifica non richiede alcuna chiave: base64url è una codifica, non una crittografia, quindi chiunque può leggere le affermazioni
Non è necessaria alcuna chiave per decodificare perché base64url è una codifica reversibile anziché una crittografia. L'intestazione e il carico utile sono destinati a viaggiare con il token e possono essere recuperati da qualsiasi detentore. Ciò consente un'ispezione utile, ma significa anche che le informazioni riservate non devono essere nascoste dietro il rumore visivo dei caratteri codificati.
L'analisi JSON aggiunge solo la struttura. Può dirti che `roles` è un array o `exp` è un numero, non che nessuno dei due valori sia autentico. ToolAcre esegue il rendering dei valori strutturati come testo e delle descrizioni registrate come documentazione, lasciando l'autorizzazione al sistema che può verificare e applicare la policy.
Esempio funzionante: un token con un carattere di payload modificato continua a decodificarsi perfettamente; solo avvisi di verifica
Inizia con un token sintetico il cui payload dice `{"sub":"demo","role":"reader"}`. Modificare un carattere del payload codificato in modo che i byte formino ancora JSON validi, magari producendo un ruolo diverso. Entrambe le versioni possono dividere, decodificare e stampare in modo grazioso. Il percorso di decodifica non ha motivo di rifiutare la versione modificata.
Un verificatore configurato correttamente ricalcola o controlla il risultato crittografico sull'input di firma modificato e rifiuta la mancata corrispondenza. Questo confronto dimostra il confine preciso: il successo del decodificatore copre la sintassi, mentre il successo del verificatore può stabilire l'integrità relativa a una chiave attendibile e a un algoritmo consentito prima che venga valutata la politica di attestazione.
Ciò non copre: il decodificatore ToolAcre JWT non verifica mai la firma, in base alla progettazione; nulla di ciò che mostra dimostra che un token è autentico
ToolAcre non verifica mai la firma. Un segmento vuoto riceve un avviso, la codifica della firma non corretta ne riceve un altro e i byte misurabili vengono segnalati come presenti ma non verificati. Nessuno di questi rami produce un verdetto autentico. L'implementazione non prevede l'acquisizione di chiavi nascoste o un percorso di esecuzione dell'algoritmo.
Anche una verifica crittografica riuscita non autorizzerebbe automaticamente un'azione. Il servizio che lo utilizza necessita ancora di controlli specifici dell'emittente, del pubblico, del tempo e dell'applicazione. Questo articolo si ferma prima della configurazione della libreria perché il supporto e le impostazioni predefinite variano; consulta l'esatto verificatore e la versione utilizzata dal tuo servizio.
Conclusione: decodifica per ispezionare, verifica per fidarsi: usa il decodificatore ToolAcre JWT per il primo e una libreria lato server con la chiave giusta per il secondo
Decodifica per ispezionare e verificare prima dell'affidamento. Utilizza lo strumento del browser per un token scaduto o sintetico quando hai bisogno di vedere i campi di intestazione, i valori del carico utile, le conversioni temporali e gli avvisi strutturali. Non lasciare mai che l'output leggibile confluisca direttamente in una decisione di accesso.
Sposta il lavoro consequenziale a un verificatore affidabile con materiale chiave fornito in modo indipendente, algoritmi bloccati e politica di servizio. Solo questo percorso può verificare l'autenticità e l'integrità e solo i successivi controlli delle rivendicazioni possono decidere l'autorizzazione. Il rifiuto di un decodificatore di offuscare questi lavori è una caratteristica di sicurezza.