L'assicurazione del client è autorizzata all'uso del token Web JSON

In una frase: devi fidarti del client per usare TLS e generalmente proteggere il token.

Come molti sistemi token, JWT si affida al client per proteggere il suo token. I clienti sono già tenuti a conservare le credenziali necessarie per l'autenticazione (ad es .: password), quindi questo non è un concetto radicalmente diverso. Inoltre, le JWT hanno in genere un tempo di scadenza molto più breve delle credenziali, quindi la loro protezione è in genere più semplice.

Di seguito sono riportati alcuni frammenti di specifiche pertinenti.

RFC JWT , che utilizza RFC JSON Web Signature , richiede l'utilizzo di TLS:

To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.

Le JWT sono simili al concetto OAuth 2.0 di token al portatore . Il token bearer RFC dichiara:

Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.

Nella sezione 5.2 prosegue dicendo che TLS deve essere usato per garantire la sicurezza del token in transito, sia quando si ottiene il token che quando lo si usa:

This requires that the communication interaction between the client and the authorization server, as well as the interaction between the client and the resource server, utilize confidentiality and integrity protection.

Chiedi al proprietario delle informazioni se autorizzano la richiesta.

Come Neil Smithline sottolinea nella sua eccellente risposta a questa domanda , le RFC su JWT, OAuth e molti altri sistemi di autenticazione basati su token si basano sull'utente che mantiene la segretezza del proprio token.

Personalmente, questa è una pillola difficile da inghiottire: molti utenti finali non capiscono cosa sia un token o dove sia, per non dire perché o come dovrebbero proteggerlo.

Anche se questo può sembrare così fondamentale è riduttivo notare che se un utente finale è consapevole qualcuno sta tentando di accedere alle proprie informazioni private, o se un utente finale è consapevole della privacy della propria chiave è stato compromesso, si potrebbe obiettare che è molto più probabile che avvertano le parti interessate che qualcosa è andato storto.

Quindi, si potrebbe concludere che il compito da svolgere è quello di progettare un sistema in cui sia facile per gli utenti essere a conoscenza di quando si accede alle loro informazioni private, quando viene utilizzato il proprio token. Anche se non possiamo progettare un sistema che non si basa sulla fiducia, possiamo progettare un sistema che leghi la protezione della chiave in interessi che l'utente ha già e sa come gestire.

In un'implementazione ipotetica di un sistema che utilizza token Web, si potrebbe sperimentare quanto segue:

1. Esegui test sull'infrastruttura dell'applicazione per assicurarti che utilizzi Perfect Forward Security.
2. Chiedi ai clienti che accedono all'infrastruttura dell'applicazione quali sono.
3. Cerca l'identificazione fornita dal client in un sistema interno che associa l'identificazione a un telefono cellulare e contatta il cellulare.
4. Il messaggio inviato al telefono fornirà quante più informazioni possibili sul client e chiederà alla persona che ha il controllo del telefono se il cliente debba essere autorizzato a utilizzare l'infrastruttura dell'applicazione.
5. Se il client è autorizzato dalla persona che detiene il controllo del telefono, invia un token al client e conserva una registrazione di come viene utilizzato il token. Inoltre, condividi parti pertinenti di quel registro con il telefono registrato.
6. Scade il token dopo un breve periodo di tempo; rifiuta ogni ulteriore richiesta usando quel token.

Sebbene i passaggi precedenti non facciano certamente parte degli RFC sui Token Web JSON, OAuth o molti altri sistemi di autenticazione basati su token, sposta parzialmente il problema della fiducia da un utente che non sa come mantenere un token sicuro ad un gruppo di ingegneri che sanno idealmente come implementare bene l'autenticazione a due fattori.