Non riesco a capire il ragionamento per rendere pubblicamente visibili le richieste / il carico utile di una JWT dopo la decodifica di base64.
Perché?
Sembra che sarebbe molto più utile averlo crittografato con il segreto.
Qualcuno può spiegare perché, o in quale situazione, mantenere pubblici questi dati è utile?
Hai scelto di non crittografare il payload per gli stessi motivi per cui hai scelto di non crittografare qualcos'altro: il costo (per quanto piccolo sia) supera il vantaggio, e molti dati semplicemente non hanno bisogno di essere protetti in questo modo .
Ciò di cui hai maggiormente bisogno di protezione è che le persone manomettano i dati in modo che il record sbagliato venga aggiornato o che l'account di controllo di qualcuno ottenga dei soldi che non dovrebbe avere. La firma del token Web di JSON lo realizza, poiché la modifica di qualsiasi parte della combinazione header / payload / signature invalida il pacchetto.
Nota che puoi ancora proteggere i pacchetti sul Transport Layer usando SSL.
L'uso del termine firma nella RFC è analogo a una firma digitale nella crittografia asimmetrica. Nella crittografia asimmetrica se il mittente crittografa un messaggio con la propria chiave privata, chiunque abbia il messaggio può decrittografarlo con la chiave pubblica del mittente. Quindi l'obiettivo con il termine firma non è quello di mantenere un messaggio segreto, ma per verificare l'integrità / mittente del messaggio, questo non è stato alterato.
Nel caso di JWTs il sistema di invio è sia il creatore che il consumatore del messaggio (vedi diagramma sotto), e l'obiettivo è di assicurarsi che il token passato all'utente non sia stato manomesso (ad es. dati privilegi elevati) .
E come citato @Robert, i JWT possono / dovrebbero essere ancora crittografati con TLS.
Ecco una buona spiegazione delle JWT e delle firme da cui proviene l'immagine qui sotto. 5 semplici passaggi per comprendere i token Web JSON (JWT)
Per aggiungere alla risposta di Robert Harveys, c'è un notevole svantaggio nella crittografia del payload - significa che il destinatario del servizio deve condividere un segreto con il server di autenticazione (la chiave di crittografia) per capire se il portatore del il token è autorizzato o meno. Al contrario chiunque può convalidare un JWT usando solo la chiave pubblica pubblicata dal server di autenticazione.
Questa è una parte fondamentale delle specifiche openid connect in quanto consente alle applicazioni client di convalidare i token di identità rilasciati dal server di autenticazione, rende inoltre più semplice la distribuzione dei server di risorse (poiché non è necessario distribuirli con accesso a la chiave di crittografia segreta) e aiuta anche quando si tenta di diagnosticare eventuali problemi con un JWT emesso.
Leggi altre domande sui tag security authentication json jwt