Strumenti per sviluppatori · Decodificatore JWT
Spiegazione dell'intestazione JWT: alg, typ, kid e i campi di cui diffidare
· Come funziona
jwt sicurezza autenticazione
L'intestazione indica al verificatore come è stato firmato il token e quale chiave utilizzare. Questo post spiega ogni campo di intestazione comune, su cosa può fare affidamento un verificatore e quali campi non devono mai essere considerati attendibili dal token stesso.
Il piccolo oggetto JSON che nessuno legge e le decisioni di verifica che influenza
L'intestazione è abbastanza piccola da poter essere trascurata, tuttavia i suoi campi spesso partecipano al routing di verifica. Ciò rende pericoloso confondere la visibilità con l’autorità. ToolAcre decodifica l'intestazione come oggetto JSON e mostra le sue proprietà, ma ogni byte proviene dal titolare del token e rimane input non attendibile.
Un verificatore può utilizzare un valore di intestazione solo all'interno dei vincoli stabiliti dalla configurazione attendibile. Non dovrebbe consentire al token di inventare un algoritmo, un emittente o una fonte di chiave remota accettati. Il lavoro del decodificatore termina con JSON leggibile più avvisi; non sceglie mai una chiave né produce una decisione di autorizzazione o negazione.
alg display: il decodificatore spiega solo gli algoritmi indicati nella sua implementazione
`alg` dichiara l'algoritmo utilizzato dalle attestazioni del token. ToolAcre contiene note esplicative per HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384 e PS512, più un avviso per `none`. Qualsiasi altra stringa viene visualizzata come non riconosciuta anziché trattata come supportata.
Questo elenco è una funzionalità di visualizzazione, non un catalogo di algoritmi che ToolAcre può verificare: non ne verifica nessuno. Un backend deve fissare le scelte consentite in modo indipendente e rifiutare una mancata corrispondenza. La lettura di `alg: RS256` non può dimostrare che sia stato utilizzato RSA, proprio come la lettura di `alg: none` non può autorizzare in modo sicuro un token non firmato.
typ e cty: dichiarano il tipo di token, il profilo at+jwt per i token di accesso e i JWT nidificati
`typ` descrive il tipo di supporto o il profilo che il produttore intende. ToolAcre avvisa quando un valore stringa è diverso da `JWT`; non impone la semantica del profilo. Un campo `cty` può descrivere contenuto nidificato, ma il decodificatore corrente non ha un percorso di elaborazione dei token nidificati e non interpreta quel campo.
La tipizzazione esplicita può aiutare un verificatore a mantenere separate le diverse classi di token quando la sua policy definisce i valori attesi. L'assegno appartiene ancora a quel verificatore. Un token non può diventare un token di accesso semplicemente annunciando un'etichetta preferita e un pannello di decodifica non può determinare quale endpoint dell'applicazione dovrebbe consumarlo.
kid: l'identificatore di chiave che consente ai verificatori di ruotare le chiavi senza tempi di inattività
`kid` è un identificatore di chiave, non materiale della chiave e non una prova di proprietà. Un servizio che ruota diverse chiavi attendibili può utilizzare un contesto di emittente autenticato e un identificatore vincolato per individuare un candidato. L'identificatore deve rimanere l'input per una ricerca controllata anziché un percorso di file, un frammento di query o un URL arbitrario.
ToolAcre lascia `kid` visibile nell'intestazione JSON ma non lo risolve. Questa limitazione è importante: nessun archivio di chiavi attendibile è disponibile per una pagina di decodifica pubblica. Se un 401 segue la rotazione, confronta l'identificatore visualizzato con l'inventario e i log delle chiavi lato server senza dare per scontato che la chiave suggerita dal token sia legittima.
jku, x5u, jwk e x5c: campi di intestazione che puntano alle chiavi e perché un verificatore non deve mai recuperarli o fidarsi ciecamente di essi
Campi come `jku` e `x5u` possono nominare posizioni, mentre `jwk` e `x5c` possono contenere dati relativi alle chiavi. La loro presenza non rende affidabili quei luoghi o quei valori. Recuperare un URL o accettare materiale incorporato solo perché fornito da un'intestazione non verificata trasmette una decisione sulla sicurezza al richiedente.
Un verificatore sicuro ottiene le chiavi attraverso una relazione con l'emittente e una politica di rete stabilita all'esterno del token. ToolAcre non recupera gli URL di intestazione né crea attendibilità dalle chiavi incorporate. Durante la revisione, la visualizzazione di uno di questi campi richiede di controllare la configurazione del verificatore, non un'istruzione di seguire l'intestazione.
crit: estensioni che un verificatore deve comprendere o rifiutare
`crit` segnala che particolari estensioni richiedono la comprensione da parte del destinatario. Un verificatore che supporti tale estensione necessita di un'implementazione esplicita e di un percorso di rifiuto per nomi critici sconosciuti. Ignorare un indicatore critico sconosciuto può far sì che produttore e consumatore interpretino il contenuto protetto in modo diverso.
L'implementazione di sola decodifica non elabora `crit`, quindi può mostrare l'array non elaborato senza richiedere la compatibilità. Questo è un altro confine tra ispezione e convalida. Se un token di produzione si basa su estensioni critiche, verifica il comportamento nella libreria e nella configurazione effettive anziché dedurre il supporto dal JSON leggibile.
Esempio pratico: leggere un'intestazione realistica e decidere quali campi informano la verifica e quali sono meramente informativi
Considera `{"alg":"RS256","typ":"JWT","kid":"rotate-7"}`. ToolAcre stampa tutti e tre i campi e spiega che la verifica di RS256 richiede una chiave pubblica dell'emittente. Un revisore può prendere nota dell'algoritmo dichiarato e dell'identificatore di chiave, quindi confrontarli con la policy bloccata del server e il set di chiavi attendibili.
I campi informano l'indagine ma non decidono nulla in modo indipendente. Se il server consente solo un altro algoritmo, non riesce a trovare `rotate-7` nel set di emittenti corretto o rifiuta la firma, l'intestazione leggibile non sovrascrive quel risultato. Allo stesso modo, non deve essere accettata la modifica del testo dell'intestazione senza ricalcolare una firma valida.
Conclusione: l'intestazione è un input, non un'autorità: il decodificatore ToolAcre JWT mostra l'intestazione in modo che tu possa leggerla; il verificatore deve decidere autonomamente di cosa fidarsi
Tratta l'intestazione JWT come input, non come autorità. I suoi valori possono aiutare a selezionare tra le scelte già autorizzate dalla configurazione, identificare un probabile problema di rotazione o spiegare una mancata corrispondenza del profilo. Non possono stabilire la fiducia nel proprio algoritmo, chiave, URL o tipo di token.
Utilizza ToolAcre per leggere un'intestazione di test e far emergere valori sospetti come `alg` mancante, `none` o un `typ` imprevisto. Quindi passa al verificatore configurato per ogni decisione consequenziale. La decodifica non dimostra l'autenticità, l'integrità, l'autorizzazione o l'identità dell'emittente, indipendentemente da quanto sia plausibile l'intestazione.