Strumenti per sviluppatori · Decodificatore JWT
Le sette affermazioni JWT registrate: iss, sub, aud, exp, nbf, iat e jti
· Sfondo
jwt formati di dati autenticazione
RFC 7519 riserva sette nomi di attestazioni con significati e tipi definiti. Questo post spiega ciascuno di essi, i tipi StringOrURI e NumericDate dietro di essi e come coesistono attestazioni registrate, pubbliche e private.
Quali nomi di attestazione dovrei utilizzare? - la domanda di progettazione a cui risponde il registro
La scelta dei nomi delle attestazioni è in parte una decisione di interoperabilità. Il riutilizzo di un nome registrato fornisce ai lettori e alle biblioteche un significato stabilito, mentre i nomi specifici dell'applicazione richiedono documentazione locale. ToolAcre riconosce sette nomi principali nella sua tabella descrittiva e lascia visibili le altre affermazioni senza assegnare la semantica.
Un nome familiare non è automaticamente affidabile. Il decodificatore legge qualunque oggetto contenga il token e non ne verifica mai la firma. Il vocabolario registrato aiuta gli esseri umani a classificare i dati; solo un verificatore fidato può stabilire che un emittente ha fornito il valore protetto.
iss e sub vengono visualizzati come stringhe; questa implementazione non impone la sintassi StringOrURI
`iss` identifica chi è stato emesso dalle dichiarazioni del token e `sub` identifica di chi o di cosa si tratta. ToolAcre descrive entrambi e ne visualizza i valori, ma la sua implementazione non convalida una grammatica StringOrURI né confronta i campi con la configurazione del servizio.
Un verificatore dovrebbe associare l’emittente previsto al materiale chiave attendibile e interpretare l’oggetto sotto lo spazio dei nomi di quell’emittente. Copiare una stringa di un emittente noto in un payload fabbricato fa sembrare convincente il decodificatore senza stabilirne l'origine. Utilizza questi campi solo dopo la verifica crittografica.
aud: i destinatari previsti, come stringa o array
`aud` descrive i destinatari previsti e può essere rappresentato come un valore o un elenco in base alle regole dei token applicabili. La tabella delle attestazioni generiche di ToolAcre conserva gli array come testo JSON ma non decide se il servizio corrente viene visualizzato al loro interno.
Il pubblico è contestuale. Lo stesso token autenticato potrebbe essere appropriato per un API e sbagliato per un altro. Un server di risorse necessita di un identificatore previsto nella configurazione attendibile e deve rifiutare una mancata corrispondenza anziché lasciare che il token definisca dove deve essere accettato.
exp, nbf e iat: le tre affermazioni NumericDate che vincolavano un token nel tempo
`exp`, `nbf` e `iat` sono attestazioni NumericDate. ToolAcre tratta i numeri finiti come secondi dall'epoca, moltiplica per 1,000 per la visualizzazione della data ed etichetta la scadenza o non prima rispetto all'orologio del browser. Non definisce il margine di manovra né impone l'accettazione del server.
Una scadenza segna un limite finale dichiarato, non una prova che il token sia mai stato valido. Non prima segna un confine di inizio dichiarato e rilasciato a registra un'ora di creazione dichiarata. Ciascuno può essere contraffatto in un carico utile, quindi l'aritmetica del tempo deve seguire la verifica della firma in un flusso affidabile.
jti: un identificatore univoco per il rilevamento dei replay e le liste bloccate
`jti` è un identificatore di token. I sistemi possono utilizzare un identificatore autenticato, opportunamente generato per il monitoraggio della riproduzione o lo stato di revoca, ma l'attestazione da sola non fornisce nessuna delle due proprietà. ToolAcre lo descrive come un ID token per il rilevamento della riproduzione e ne visualizza il valore esatto.
L'unicità, l'archiviazione e il comportamento di ricerca appartengono all'architettura dell'emittente e del verificatore. Un decodificatore non può determinare se un altro token ha riutilizzato l'identificatore o se una lista nera lo contiene. Trattatelo come un valore di correlazione candidato finché il sistema attendibile circostante non fornisce prove.
Descrizioni registrate e affermazioni specifiche dell'applicazione nella visualizzazione ToolAcre
L'implementazione distingue i nomi registrati solo attraverso il testo esplicativo. Ogni proprietà del payload viene comunque restituita da `listClaims`; i nomi sconosciuti ricevono una descrizione nulla e l'interfaccia utente li etichetta come specifici dell'applicazione. Non consulta un registro pubblico né impedisce collisioni tra nomi privati.
Questo confine evita di affermare più di quanto dimostra la fonte. I team dovrebbero documentare le loro rivendicazioni private e scegliere nomi resistenti alle collisioni quando l’interoperabilità è importante. L’assenza di una descrizione del decodificatore significa “non in questa tabella locale di sette nomi”, non “non valido” o “sicuro da ignorare”.
Esempio pratico: leggere un carico utile realistico e classificare ogni richiesta
Considera `{"iss":"https://issuer.example","sub":"user-7","aud":["orders"],"exp":1717246800,"nbf":1717243100,"iat":1717243200,"jti":"demo-9","tenant":"north"}`. ToolAcre descrive i sette campi registrati e le etichette `tenant` specifiche dell'applicazione durante la formattazione dei tre tempi numerici.
Questa classificazione aiuta a rivedere la progettazione del carico utile. Non autentica URL, oggetto, pubblico, date, identificatore o tenant. Un gettone forgiato può riprodurre esattamente l'oggetto. Inserisci solo le attestazioni verificate nella logica di autorizzazione, quindi applica i valori previsti del servizio di consumo.
Conclusione: usa i nomi registrati quando si adattano: il decodificatore ToolAcre JWT mostra il payload in modo da poter vedere quali affermazioni imposta un vero emittente
Utilizzare nomi registrati quando i loro significati definiti si adattano, perché il vocabolario riconoscibile riduce le traduzioni inutili. Mantieni i campi privati documentati e minimi. Non sovraccaricare `sub`, `aud` o un'attestazione temporale con un significato locale diverso semplicemente perché il codice downstream analizza già quella chiave.
ToolAcre può mostrare quali nomi porta un token sicuro e come vengono visualizzate le sue attestazioni numeriche. Non può certificare alcun valore. Il risultato utile della decodificazione è un inventario per la revisione; il risultato utile della verifica e della politica è una decisione, e queste rimangono separate.