Sono l'autore di questo articolo, così come il popolare discorso di tecnologia che do sul perché i JWT fanno schifo e sono stupidi (tutto ciò @ joepie91 ha scritto eloquentemente su molto meglio di quanto io abbia mai potuto: link ).
Dati i requisiti dell'applicazione (app per dispositivi mobili + JS front-end che comunicano entrambi con un'API di back-end), ti suggerisco di utilizzare il flusso del codice di autorizzazione di OpenID Connect (con PKCE per l'app per dispositivi mobili).
Per la tua app mobile, in particolare, ti consiglio di utilizzare la favolosa libreria AppAuth: link (ha ottime librerie sia per iOS che per Android ).
Ora ti starai chiedendo perché raccomando di usare OpenID Connect (e quindi JWT) per qualcosa quando raduno pubblicamente le persone contro l'utilizzo di JWT: ti dirò che per la maggior parte delle cose non importa .
Ecco la cosa: sì, le JWT sono piuttosto orribili da usare quando si creano app sicure. Sono complicate, la maggior parte delle librerie al momento non sono complete, e l'uso di funzionalità più avanzate come la crittografia JWT è quasi certo che causerà enormi problemi e problemi di compatibilità tra i servizi.
Inoltre, l'intera ragione per cui i JWT sono diventati popolari per l'autenticazione è che sono frequentemente utilizzati per l'autenticazione e i dati di autorizzazione CACHE: questa pratica è un grande NO NO nel mondo della sicurezza.
La memorizzazione nella cache di dati sensibili (come i dati di autenticazione e autorizzazione) è la cosa peggiore che tu possa mai fare per la sicurezza: ti stai fidando delle informazioni obsolete. TUTTI gli attuali sistemi di autenticazione basati su JWT soffrono di questa ingenuità.
Una volta che hai colto il buco del coniglio nel tentativo di "accelerare" il tuo sito / API utilizzando le JWT, hai già commesso un errore di sicurezza e ora sei a rischio.
Inoltre, una volta che le persone iniziano a utilizzare le JWT e si rendono conto che sono a rischio, cercano di ricentrare tutto (come un altro commentatore ha suggerito) e iniziare a utilizzare gli elenchi di revoche in modo che possano revocare i token quando accadono cose brutte. Ciò comporta le stesse penalità per la velocità rispetto alla gestione tradizionale delle sessioni, ma con una maggiore velocità delle penalità dovute al fatto che le JWT sono "più pesanti" dei cookie di sessione e più fragili.
Ci scusiamo per il rant, ma ecco il mio consiglio:
- Se si desidera la sicurezza reale , è necessario utilizzare le sessioni sul lato server. Nel tuo caso, ciò comporterebbe il supporto dei cookie di sessione dal tuo backend API in modo che quando l'app di reazione autentica la tua API, l'API imposta un cookie sicuro che l'app reagisce automaticamente ogni volta che risponde al servizio API per l'autenticazione. Dovresti anche utilizzare un'API basata su cookie dalla tua app per dispositivi mobili (non ho familiarità con la creazione di app native per dispositivi mobili, quindi non posso commentare questo componente).
- Se vuoi la semplicità e la stessa sicurezza di quasi tutte le altre principali app Web, utilizza OIDC e vai con le soluzioni open source pronte all'uso. Questo è il modo più semplice di andare al momento e mentre non è perfetto, se risolve il tuo problema allora probabilmente non è un grosso problema.
Se stai creando qualcosa di sensibile, prova a utilizzare i cookie di sessione lato server quando possibile. Altrimenti? Non sudare i dettagli e segui il flusso.