Strumenti per sviluppatori · Decodificatore JWT
Anatomia di un JWT: suddivisione in punti e decodifica Base64url
· Come funziona
jwt codifica sicurezza
Un JWT è composto da tre segmenti base64url separati da punti. Questo post decodifica manualmente ogni parte, spiega perché il segmento della firma non è testo e mostra cosa può e non può dirti un decodificatore.
La lunga stringa nell'intestazione Autorizzazione: cosa stai guardando e perché ha esattamente due punti
Un token al portatore spesso arriva in un'intestazione di autorizzazione come una stringa compatta, separata da punti. Un tipico JWT firmato in forma compatta JWS ha tre segmenti e quindi due punti di separazione. Un token attivo è una credenziale: non incollare i token di produzione in una dimostrazione.
Serializzazione compatta: intestazione, payload e firma come tre segmenti base64url
Nella serializzazione compatta JWS il primo segmento è l'intestazione protetta, il secondo è il payload e il terzo è una firma o MAC. La firma copre i primi due segmenti codificati, uniti da un punto. La divisione della stringa individua i segmenti; non può stabilire la fiducia.
Base64url senza riempimento: l'alfabeto utilizzato da JWS e il motivo per cui i segmenti non hanno segni di uguale finale
Base64url utilizza - e _ al posto di + e / nel Base64 ordinario. Compact JWS omette il finale = riempimento; un decodificatore può ripristinare il riempimento prima della decodifica. La decodifica produce byte. Per l'intestazione e le attestazioni JSON, decodifica i byte come UTF-8 prima di analizzare il testo.
L'intestazione: un piccolo oggetto JSON che nomina l'algoritmo e, spesso, la chiave
L'intestazione è solitamente JSON contenente alg e talvolta un identificatore chiave, kid. Queste sono affermazioni fatte dal token stesso. Un verificatore deve applicare la propria politica di algoritmo consentito e ottenere in modo sicuro la chiave appropriata; leggere alg da solo non è un'autorizzazione.
Il payload: un JSON oggetto di attestazioni, leggibile da chiunque detenga il token
Il payload contiene affermazioni come sub, exp e aud. Chiunque abbia il token può leggerli; la codifica non è la crittografia. Un exp NumericDate conta i secondi dall'epoca di Unix, ma un'affermazione non verificata non ha autorità. Non archiviare i segreti in un payload leggibile.
La firma: byte grezzi sui primi due segmenti, privi di significato come testo e inutili senza una chiave
L'ultimo segmento sono i byte della firma codificati in base64url, non un terzo oggetto JSON. La convalida richiede un algoritmo crittografico, una chiave e una policy applicativa. ToolAcre deliberatamente non esegue la verifica: segnala la presenza della firma e contrassegna sempre SignatureVerified come falso.
Esempio funzionante: decodifica di un token di esempio segmento per segmento, incluso JSON che appare
Prendi l'intestazione dimostrativa non sensibile {"alg":"HS256","typ":"JWT"} e il payload {"sub":"demo"}. Le loro codifiche base64url sono eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 e eyJzdWIiOiJkZW1vIn0. La decodifica recupera JSON. L'aggiunta di un terzo segmento arbitrario non rende il token autentico.
Conclusione: la decodifica significa leggere, non fidarsi: il decodificatore ToolAcre JWT mostra l'intestazione e il payload e non verifica mai la firma, quindi nulla di ciò che mostra dimostra che il token è autentico
Decodificare significa leggere, non fidarsi. Utilizza il decodificatore ToolAcre JWT per l'intestazione, le rivendicazioni e gli avvisi di un token usa e getta; utilizza il verificatore attendibile della tua applicazione per decidere se un token firmato è valido. Le sole attestazioni visualizzate non devono mai garantire l'accesso.