Strumenti per sviluppatori · Decodificatore JWT
Token ID e token di accesso: perché un OpenID Connect JWT non è una chiave API
· Sfondo
jwt oauth autenticazione
Entrambi possono essere JWT dello stesso fornitore, ma rispondono a domande diverse. Questo post spiega cosa contengono ciascuno un token ID e un token di accesso, chi dovrebbe consumarli e come distinguerli tramite decodifica.
API rifiuta un token che sembra perfettamente valido, perché non è mai stato pensato per API
Un API può rifiutare un token ben formato e firmato correttamente perché la credenziale è stata emessa per un altro consumatore e scopo. "È un JWT" descrive un possibile formato, non l'autorizzazione a inviarlo ovunque. I token ID e i token di accesso rispondono a domande diverse in un flusso di identità.
ToolAcre può esporre modelli di intestazione e payload che supportano il debug, ma non può autenticare il token o convalidare un profilo OpenID Connect. La classificazione finale deve derivare dal contratto del fornitore, dal flusso di emissione e dal risultato della verifica attendibile piuttosto che dall'ispezione visiva.
Le attestazioni del token ID possono suggerire l'uso dell'identità; questo decodificatore generico non convalida un profilo OpenID Connect
Un token ID comunica le informazioni di autenticazione al client che ha richiesto l'accesso. A seconda del profilo, le attestazioni visibili possono includere un nonce, l'ora di autenticazione, i metodi di autenticazione o un hash relativo a un altro token. Questi campi non sono concessioni di autorizzazione API generiche.
Il decodificatore tratta `auth_time` come un campo a forma di tempo e visualizza gli altri nomi come specifici dell'applicazione a meno che non siano tra i suoi sette principali. Non convalida nonce, `at_hash`, `amr` o la semantica del pubblico del client. Un payload di identità leggibile rimane non attendibile finché il client non lo convalida correttamente.
I token di accesso possono essere JWT o opachi; solo i JWT in tre parti si adattano a questo decodificatore
Un token di accesso autorizza le chiamate a un server di risorse in base a un sistema di autorizzazione. Potrebbe essere un JWT o una stringa opaca. Solo la forma firmata in tre parti si adatta al percorso di ToolAcre; un token opaco non ha una struttura generale lato client da decodificare e non deve essere forzato tramite questo strumento.
Un token di accesso JWT può contenere informazioni sul pubblico e sull'ambito, ma tali valori richiedono una verifica autenticata e una policy sulle risorse. Il pannello del browser non implementa un server di risorse e non è in grado di stabilire se un ambito consente una particolare operazione.
Token di aggiornamento: solitamente opachi, mai destinati a essere decodificati e mai inviati a un API
Un token di aggiornamento supporta l'ottenimento di credenziali di accesso sostitutive in base alle regole del provider. In genere è opaco e non è destinato alle API delle risorse. È anche una credenziale di alto valore, quindi incollarla in un decodificatore crea rischi senza un vantaggio diagnostico affidabile.
Non dedurre che ogni valore a forma di token debba essere decodificato. Utilizza gli strumenti del provider e i log controllati per gli errori di aggiornamento. L'avvertimento esplicito di ToolAcre contro i token di produzione si applica con particolare forza in questo caso e il suo parser a tre segmenti non offre alcuna operazione di aggiornamento.
I segmenti di pubblico differiscono: l'ID cliente in un token ID rispetto alla risorsa in un token di accesso
Il pubblico è un indizio forte perché il consumatore previsto è diverso. Un token ID spesso prende di mira il client, mentre un token di accesso prende di mira una risorsa. Gli identificatori e le rappresentazioni esatte dipendono dal provider e dal profilo, pertanto questo articolo non inventa uno schema di stringa universale.
Un'intestazione `typ` può anche fornire un'etichetta esplicita, ma rimane un dato controllato da token fino alla verifica. ToolAcre avvisa solo quando una stringa `typ` differisce da `JWT`; non riconosce ogni etichetta del profilo né ne trasforma una in una decisione di autorizzazione.
Esempio realizzato: confrontare i campi visibili senza trattarli come prova del tipo di token
Decodifica due esempi sintetici: uno che trasporta richieste di autenticazione orientate al client e uno che trasporta un pubblico e un ambito di risorse. Registra le differenze in `aud`, `typ` e nei nomi dei carichi utili. L’esercizio insegna cosa chiedere all’emittente, non come dimostrare l’identità dell’uno o dell’altro esempio.
Un token fabbricato può copiare le stesse etichette e un token reale può utilizzare convenzioni specifiche del provider. Conferma il tipo dalla risposta all'emissione e dalla documentazione, quindi convalidalo con il consumatore previsto. L’output del decodificatore costituisce una prova a sostegno, mai l’autorità decisionale.
Ciò che questo non copre: i flussi OAuth che emettono questi token, che sono un argomento separato
Questo confronto non spiega il codice di autorizzazione, il dispositivo o altri flussi che emettono token. Inoltre, non copre le fasi di convalida specifiche del provider, l'introspezione opaca dei token di accesso o la rotazione degli aggiornamenti. Tali argomenti dipendono dall’ecosistema selezionato e dall’implementazione.
Mantenere ristretta la domanda di debug immediato: quali credenziali ha ricevuto il client, chi è il consumatore previsto e quale componente attendibile lo convalida? Rispondere a queste tre domande impedisce a una forma generica JWT di cancellare i ruoli del protocollo.
Conclusione: controlla aud e digita prima di inviare: il decodificatore ToolAcre JWT ti consente di verificare quale tipo di token hai in mano
Osserva il pubblico e digita prima di inviare un token, ma non fidarti di nessuno dei due campi finché la verifica non ha esito positivo. Un token ID appartiene al limite di convalida del client; un token di accesso appartiene al relativo server di risorse. Un token di aggiornamento appartiene al processo di aggiornamento del provider, non a API.
ToolAcre aiuta a leggere esempi sicuri in tre parti e non ha alcuna pretesa di classificarli o convalidarli. Usalo per individuare probabili errori, quindi lascia che il flusso documentato e il verificatore configurato in modo indipendente stabiliscano il vero scopo della credenziale.