Strumenti per sviluppatori · Decodificatore JWT
Controlli del pubblico e dell'emittente: impedire che JWT venga riprodotto altrove
· Perché è importante
jwt autenticazione sicurezza
Un token emesso per un servizio può essere presentato a un altro che condivide lo stesso emittente. Questo post spiega come i controlli aud e iss interrompono ciò e come leggere entrambe le affermazioni in un token.
Il servizio B accetta un token destinato al servizio A: la riproduzione tra servizi che una firma valida non impedisce
Una firma può essere valida per un token rilasciato a un servizio diverso. Se diverse API si fidano della stessa piattaforma di identità ma ignorano il contesto del destinatario, una credenziale destinata al servizio A potrebbe essere riprodotta nel servizio B. L'integrità crittografica da sola non determina chi dovrebbe utilizzarla.
ToolAcre può rivelare `iss` e `aud` in modo che uno sviluppatore possa individuare un'evidente mancata corrispondenza. Tali stringhe rimangono non verificate finché la firma non ha esito positivo e lo strumento del browser non esegue mai tale controllo. Il server di risorse effettivo deve rafforzare sia la relazione con l'emittente che il pubblico previsto.
iss: associare un token all'emittente di cui il tuo servizio si fida e perché una corrispondenza di stringa non è sufficiente senza l'associazione di chiavi
`iss` identifica l'entità da cui le affermazioni del payload hanno emesso il token. Un verificatore necessita di un esatto emittente previsto nella propria configurazione e deve associare tale identità alla corretta relazione di rilevamento delle chiavi. Il confronto del testo senza l'associazione crittografica lascia spazio a un utente malintenzionato per copiare la stringa prevista.
Il decodificatore descrive `iss` come "chi ha creato il token", ma questo è il significato registrato, non una scoperta su un valore incollato. Il testo leggibile dell'emittente è una prova utile per il debug della configurazione. Non può selezionare una fonte di chiave arbitraria o autenticarsi.
aud: una stringa o un array che nomina i destinatari previsti e la regola secondo cui un verificatore deve trovarsi al suo interno
`aud` nomina i destinatari previsti e può apparire come una stringa o una raccolta. La policy del server di risorse deve trovarsi nel valore autenticato utilizzando le esatte regole di confronto richieste dal suo profilo. Non dovrebbe accettare un token semplicemente perché è elencato qualche altro servizio familiare.
ToolAcre trasporta gli array come testo JSON nella tabella delle attestazioni, preservandone la struttura visibile per l'ispezione. Non conosce l'identificatore corrente di API e non può decidere una corrispondenza. Tale assenza deliberata impedisce ad un decodificatore generico di inventare un contesto di autorizzazione di cui non dispone.
azp e scope: le affermazioni OpenID Connect e OAuth definiscono chi può utilizzare il token e per cosa
`azp` e `scope` possono aggiungere contesto su una parte autorizzata e sulle autorizzazioni richieste nei profili che li definiscono. Non sostituiscono i controlli del pubblico, dell'emittente o della firma. Un nome di ambito è un'asserzione, non una concessione di autorizzazioni finché il server di risorse non associa un valore autenticato alla propria policy.
L'attuale decodificatore le tratta come affermazioni specifiche dell'applicazione perché la sua tabella delle descrizioni registrate copre sette nomi principali. Visualizza i loro valori ma non fornisce alcuna semantica OpenID Connect o OAuth. Consultare il profilo applicabile e il contratto del fornitore prima di utilizzarli in una decisione.
Il modello del sostituto confuso: come un token legittimo diventa un attacco quando il pubblico non viene controllato
Un deputato confuso usa l'autorità legittima in un contesto non voluto. Un token accettato dal servizio sbagliato può innescare esattamente quel modello anche quando nessuno ha falsificato la firma. I controlli del pubblico limitano i casi in cui possono essere applicate le affermazioni autenticate, mentre i controlli dell'emittente limitano le asserzioni prese in considerazione dal servizio.
Ecco perché un flag generale di “firma valida” sarebbe ancora insufficiente. L'autorizzazione dipende dal destinatario e dall'operazione. ToolAcre evita completamente questa ambiguità non segnalando alcun risultato di verifica, lasciando che sia il servizio utilizzatore a combinare la crittografia con la policy contestuale.
Esempio funzionante: leggere iss e aud da due token nel decodificatore ToolAcre JWT e decidere quale servizio deve accettarli ciascuno
Crea due token innocui i cui payload decodificati differiscono solo in `aud`: uno si chiama `service-a`, l'altro `service-b`; entrambi rivendicano lo stesso emittente. ToolAcre rende visibile la differenza. Un verificatore del servizio A non dovrebbe accettare nessuno dei due semplicemente da questa visualizzazione e dovrebbe rifiutare il pubblico del servizio B autenticato.
Quindi invertire l'esercizio con due stringhe di emittenti. Il testo previsto da solo non è sufficiente a meno che la verifica non abbia utilizzato chiavi attendibili per quell'emittente. Questi esempi separano l'ispezione dall'accettazione e mostrano perché copiare le affermazioni corrette in un token fabbricato non modifica alcuna politica attendibile.
Cosa non copre: verifica della firma, che il decodificatore non esegue mai; i controlli aud e iss contano solo dopo che la firma è stata mantenuta
I controlli del pubblico e dell'emittente contano solo dopo che la verifica crittografica ha stabilito che i byte protetti corrispondono a materiale di chiave attendibile. ToolAcre non esegue nessuna di queste verifiche. Il suo output non può stabilire che un reclamo sia sopravvissuto intatto o che un emittente noto ne sia l'autore.
Inoltre non recupera metadati, non sceglie chiavi né confronta i destinatari configurati. Utilizza test e log di backend per dimostrare il rifiuto per l'emittente sbagliato e il pubblico sbagliato. Una corrispondenza visiva in un decodificatore è un indizio di debug, mai una prova di autorizzazione sufficiente.
Conclusione: controlla a chi è destinato, non solo chi lo ha firmato: il decodificatore ToolAcre JWT mostra le affermazioni aud e iss che devi confrontare
Controlla a chi è destinato il token, non solo al nome che dice che lo ha firmato. Il flusso robusto autentica i byte protetti nell'ambito di una relazione con un emittente di fiducia indipendente, quindi richiede un pubblico accettabile e applica regole di autorizzazione specifiche del servizio.
Utilizza ToolAcre per leggere i valori dei test sicuri e formulare il successivo controllo lato server. Non scegliere chiavi di verifica da intestazioni o dati di richiesta non attendibili e non trasformare `iss`, `aud`, `azp` o `scope` visualizzati in una concessione senza il flusso attendibile completo.