I token di aggiornamento JWT nel browser sono davvero così brutti?

Nota: Riconosco pienamente che potrebbe esserci qualcosa che mi manca nella foto, che è parte della mia motivazione per la pubblicazione. Mi piacerebbe avere l'opinione di persone più esperte di me su implementazioni correlate a authN / Z.

Ecco dove sono bloccato su tutto "nessun token di aggiornamento sulle app client":

L'assunto che faccio è che senza un token di aggiornamento, non possiamo, per motivi di esperienza utente, avere sempre un token di accesso di durata molto breve, cioè se avessimo un token di accesso che scade ogni 15 minuti senza alcuna possibilità di aggiornando avremmo dovuto effettuare nuovamente il login ogni 15 minuti.

Il mio problema: estendendo la durata del token di accesso stiamo dando a un potenziale attaccante MIDM un'arma molto più pericolosa, cioè un gettone che dà accesso alle risorse che potrebbero durare giorni o anche per sempre (come ho visto in troppi progetti).

Per me, il modo più semplice per risolvere una situazione del genere è un token di aggiornamento, anche uno che si trova sul front-end, perché a mio avviso questo batte ancora un token ACCESS di lunga durata.

Questo token di aggiornamento potrebbe essere:

• Anche una JWT che scade, ma forse scade tra una settimana circa
• Un token "use only once" che viene utilizzato per aggiornare il token di accesso e quindi viene sostituito da un nuovo token di aggiornamento

Ai miei occhi, questo approccio contro il token di accesso di lunga durata risolve alcuni problemi:

• con questo approccio, ottengo un token di accesso di breve durata, quindi se cade in mani cattive non può essere usato per molto tempo

• se pensi che il token di aggiornamento sia ancora peggio, non sono d'accordo, perché ci sono due cose che lo rendono migliore:

  1. una volta che l'utente principale aggiorna nuovamente il token che il token di aggiornamento precedente non sarà più utilizzabile
  2. se supponiamo che qualcuno rubi il nostro token di aggiornamento mentre navighiamo, in pochi minuti il nostro browser proverà a utilizzare quel token di aggiornamento, fallirà (perché qualcun altro lo ha usato e quindi non è più utilizzabile) e ci chiede di login, che annullerà di nuovo completamente l'altra serie di token di aggiornamento ottenuta dall'entità dannosa
  3. anche se 1 e 2 non erano vere in tutti gli scenari (sto pensando che più token di aggiornamento / sessioni consentiti, quindi non un singolo stack o token di aggiornamento ma multipli) scommetterei comunque che stai meglio disabilitando i token di aggiornamento attraverso qualsiasi procedura tu voglia di invalidare i token di accesso. un token di accesso JWT è valido in sé e l'intero scopo di usarne uno è che ci si può fidare semplicemente verificandolo, senza dover fare altre costose operazioni come il controllo con il server di autenticazione se è in blacklist o meno. Ciò significherebbe essenzialmente dover controllare questo genere di cose per OGNI richiesta MAI fatto con OGNI token di accesso = non molto scalabile, specialmente se si confronta questo con il solo fatto di dover fare questo genere di ONCE ogni 15 minuti per il token di aggiornamento (si potrebbe mantenere una lista nera dei token di aggiornamento).

Quindi, con tutto ciò detto, sta avendo un token di aggiornamento "use once" dal lato client che è anch'esso un JWT e scade così irragionevole? Stiamo evitando di avere il token di accesso le ultime settimane, come può essere male?