Il modello di base che descrivi è fondamentalmente il modo più semplice per creare un sistema di gestione delle sessioni stateful. I tuoi utenti otterrebbero un token di sessione opaco (una stringa in modo sicuro casuale di almeno 128 bit di lunghezza), di solito impostato in un cookie con flag di sicurezza. Normalmente si dovrebbe avere una tabella che memorizza sessioni attive, con il token di sessione come chiave primaria e le chiavi esterne che puntano alla tabella Utenti (più eventuali metadati necessari, come i dati di scadenza della sessione, non fare affidamento sul cookie in corso lontano quando dovrebbe). Naturalmente, si presume che non sia possibile archiviare le sessioni in memoria (forse sono di lunga durata o che devono essere memorizzate su server) e ha un notevole impatto sulle prestazioni (molte chiamate al database), quindi di solito useresti molta cache.
Se si desidera utilizzare questo modello ma impedire a un utente malintenzionato che legge con successo la propria tabella Session di impersonare le sessioni attive, è possibile farlo eseguendo ciascun token tramite una funzione hash (come SHA-256 *) prima di memorizzarlo in il database (o cercandolo nel database). Ciò rende ancora possibile controllare rapidamente un determinato token nel database, ma rende praticamente impossibile passare dal vedere il database alla conoscenza dei token validi.
* Va bene usare un hash veloce qui (a differenza delle password), perché la stringa di input è già troppo alta entropia per un hacker alla ricerca di forza bruta. Allo stesso modo, non hai bisogno di sale (anche se l'aggiunta di una non danneggerà nulla tranne alcune prestazioni) perché 2 ^ 128 è un numero troppo grande per una tabella arcobaleno.