A tutti piace il modo in cui le app native chiedono di effettuare l'accesso una sola volta e ricordano i dati fino a quando non dica di disconnettersi. Purtroppo il web non funziona sempre così.
Ora che i dispositivi, in particolare i dispositivi mobili, sono più personali e che più siti inviano tutto il traffico tramite HTTPS riducendo il rischio di furto di token, i siti web dovrebbero riconsiderare i propri criteri relativi ai cookie di breve durata e adottare sessioni più facili da usare e di maggiore durata.
Tuttavia, anche se vuoi prolungare la durata della sessione, alcuni siti web non verificano l'autenticazione dell'utente per ogni richiesta (in altre parole, non è possibile revocare il cookie di sessione una volta emesso). Questo normalmente comporta sessioni brevi, in cui l'utente è costretto ad accedere frequentemente in modo che la sua autenticazione possa essere riconvalidata, consentendo ad esempio di cambiare la password di invalidare le sessioni esistenti in un periodo di tempo noto.
Se utilizzi questo approccio, abbiamo una soluzione tecnica che potrebbe aiutarti a riconvalidare automaticamente il cookie di autenticazione stateless. Funziona avendo un token secondario di lunga durata che può essere utilizzato per aggiornare il cookie di autenticazione di breve durata esistente. L'uso del nuovo pattern del service worker ci consente di "eseguire regolarmente il controllo" con il token di lunga durata, di verificare l'autenticazione dell'utente (ad esempio, per controllare se non ha modificato le password o se non ha revocato la sessione di recente) e di riemettere un nuovo cookie di autenticazione di breve durata.
Una proposta pratica per la migrazione a sessioni lunghe e sicure sul web
Da qui, questo post descrive una nuova tecnica che stiamo proponendo, chiamata 2-Cookie-Handoff (2CH). Contiamo sulla possibilità di consultare questo articolo per ricevere feedback della community e sapere se questo approccio sembra positivo e, in tal caso, di collaborare con il settore per documentare le best practice per l'utilizzo di 2 canali.
I Service worker sono una nuova tecnologia supportata da diversi browser, come Chrome, Firefox e Opera, e sarà presto disponibile su Edge. Ti consentono di intercettare tutte le richieste di rete del tuo sito attraverso un punto di codice comune sul client, senza modificare le pagine esistenti. Ciò consente di impostare un "lavoratore 2CH" per gli utenti che hanno effettuato l'accesso in grado di intercettare tutte le richieste di rete effettuate dalla tua pagina ed eseguire lo scambio di token proprio come fanno le app mobile.
Nella maggior parte dei casi il server ha già un endpoint utilizzato dalle app mobile per ottenere un nuovo token di breve durata, in genere utilizzando il protocollo OAuth. Per abilitare il pattern precedente sul web, è sufficiente aggiornare l'endpoint per capire quando viene chiamato da un service worker, per poi restituire un nuovo cookie di sessione di breve durata formattato in modo già previsto da altre pagine del sito.
Se il tuo server non dispone già di un endpoint di questo tipo, può crearne uno solo per la gestione delle sessioni del browser.
Il pattern a due token con i service worker segue piuttosto molto scrupolosamente il pattern OAuth 2.0; se esegui già un endpoint del token OAuth, è probabile che tu possa riutilizzarlo con i service worker per l'autenticazione web.
Forse ti starai chiedendo anche cosa succede se l'utente visita un browser che non supporta i service worker. Se implementi l'approccio descritto sopra, non riscontreranno differenze e continueranno a registrare sessioni brevi.
Abbiamo pubblicato un client e un backend di esempio. Ci auguriamo che proverai in prima persona e rispondi a un sondaggio sulla gestione delle sessioni.