Apprezziamo tutti il modo in cui le app native ti chiedono di eseguire l'accesso una sola volta e di ricordarti finché non comunichi di voler uscire. Purtroppo il Web non sempre funziona in questo modo.
Ora che i dispositivi, in particolare quelli mobili, sono più personali e con un numero maggiore di siti che inviano tutto il traffico tramite HTTPS riducendo il rischio di furto di token, i siti web devono riconsiderare le loro norme relative ai cookie di breve durata e adottare sessioni più lunghe e facili da usare.
Tuttavia, anche se vuoi prolungare la durata della sessione, alcuni siti web non verificano l'autenticazione dell'utente a ogni richiesta (in altre parole, non è possibile revocare il cookie di sessione una volta emesso). Questo di solito comporta sessioni brevi e l'utente è costretto ad accedere frequentemente in modo che la sua autenticazione possa essere convalidata nuovamente, ad esempio la modifica della password, per invalidare le sessioni esistenti in un periodo di tempo noto.
Se questo è un approccio che utilizzi, abbiamo una soluzione tecnica che può aiutarti a riconvalidare automaticamente il cookie di autenticazione stateless. Funziona perché dispone di un token secondario di lunga durata che può essere utilizzato per aggiornare il cookie di autenticazione di breve durata esistente. Il nuovo pattern di service worker ci consente di eseguire regolarmente il "check-in" con il token di lunga durata, verificare l'autenticazione dell'utente (ad esempio, controllare se non ha modificato le password o se non ha altrimenti revocato la sessione di recente) ed emettere 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 proponiamo e che chiamiamo 2-Cookie-Handoff (2CH). Speriamo di usare questo articolo per ascoltare i feedback della community e capire se questo approccio sembra positivo e, in questo caso, per collaborare con il settore alla documentazione delle best practice per l'utilizzo di 2CH.
I Service worker sono una nuova tecnologia supportata da più browser come Chrome, Firefox, Opera e presto disponibile su Edge. Consentono di intercettare tutte le richieste di rete provenienti dal tuo sito tramite un punto di codice comune sul client, senza modificare le pagine esistenti. Questo ti consente di configurare un "lavoratore 2CH" per gli utenti che hanno eseguito l'accesso in grado di intercettare tutte le richieste di rete effettuate dalla tua pagina ed eseguire lo scambio di token proprio come le app mobile.
Nella maggior parte dei casi il server dispone già di un endpoint utilizzato dalle app mobile per ottenere un nuovo token di breve durata, in genere mediante il protocollo OAuth. Per attivare il pattern precedente sul web, è sufficiente aggiornare quell'endpoint per capire quando viene chiamato da un service worker, quindi restituire un nuovo cookie di sessione di breve durata formattato in un modo che altre pagine del sito si aspettano.
Se il 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 il pattern OAuth 2.0 abbastanza vicino. Se hai già eseguito un endpoint del token OAuth, è probabile che tu possa riutilizzarlo con i service worker per l'autenticazione web.
Forse ti starai anche chiedendo cosa succede se l'utente visita un browser che non supporta i service worker. Se implementi l'approccio sopra indicato, non noteranno alcuna differenza e continueranno a usufruire di sessioni brevi.
Abbiamo pubblicato un client e un backend di esempio. Ci auguriamo che provate in autonomia e rispondiate a un sondaggio sulla gestione delle sessioni.