Token Web JSON: perché il payload è pubblico?

Non riesco a capire il ragionamento per rendere pubblicamente visibili le richieste / payload di un JWT dopo averlo decodificato in base64.

Perché?

Sembra che sarebbe molto più utile averlo crittografato con il segreto.

Qualcuno può spiegare perché o in quale situazione è utile mantenere questi dati pubblici?

Scegli di non crittografare il payload per gli stessi motivi per cui decidi di non crittografare nient'altro: il costo (per quanto piccolo sia) supera il vantaggio e molti dati semplicemente non devono essere protetti in questo modo.

Ciò di cui hai principalmente bisogno di protezione sono le persone che manomettono i dati in modo che il record errato venga aggiornato o che il conto corrente di qualcuno ottenga denaro in esso che non dovrebbe avere. La firma del token Web JSON lo fa, poiché la modifica di qualsiasi parte della combinazione intestazione / payload / firma invalida il pacchetto.

Si noti che è ancora possibile proteggere i pacchetti a livello di trasporto utilizzando 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 disponga del messaggio può decrittografarlo con la chiave pubblica del mittente. Quindi l'obiettivo con il termine firma non è mantenere un messaggio segreto, ma verificare l'integrità / il mittente del messaggio, che non è stato modificato.

Nel caso di JWT, il sistema di invio è sia il creatore che il consumatore del messaggio (vedere lo schema seguente) e l'obiettivo è assicurarsi che il token passato all'utente non sia stato manomesso (ad esempio, dati i privilegi elevati).

E come menzionato @Robert, i JWT possono / dovrebbero comunque essere crittografati con TLS.

Ecco una buona spiegazione dei JWT e delle firme da cui proviene l'immagine seguente. 5 semplici passaggi per comprendere i token Web JSON (JWT)

Per aggiungere alla risposta di Robert Harveys, c'è uno svantaggio significativo 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 token è autorizzato o meno o no. Al contrario, chiunque può convalidare un JWT usando solo la chiave pubblica pubblicata dal server di autenticazione.

Questa è una parte fondamentale della specifica openid connect in quanto consente alle applicazioni client di convalidare i token di identità emessi dal server di autenticazione, inoltre semplifica la distribuzione di server di risorse (poiché non devono essere distribuiti con accesso alla crittografia segreta chiave) e aiuta anche quando si tenta di diagnosticare eventuali problemi con un JWT emesso.