Un poco incasinata sinceramente.

L'idea da questo punto di vista e' di stipare informazioni di tracciamento e sincronizzazione + info sensibili in locazioni diverse in modo che i controlli possa assicurare che :

- sulla rete viaggino il minor numero di info sensibili possibile
- sia sempre possibile identificare il corretto utente in base una serie di controlli eseguiti su info eterogenee inviate da contesti differenti(cookie,user agent, ip etc..)

Quindi nel database devi mantenere i dati sensibili che saranno usati da opportune procedure per poter generare le stringhe di sincronizzazione, tali stringhe si generano con tecniche di hahing in quanto non sono reversibili (a differenza di tecniche di crittografia).

Quindi io farei una cosa del genere

1- database con i dati utente
2- database colonne per gestione accessi :
+ timestamp ultimo login eseguito
+ id sessione corrente
+ timeout massimo per il controllo utente(opzionale ma se ti serve un livello alto puo' essere utile)
+ token privato di controllo (stringa casuale assegnata all'utente e utilizzata per generare gli hash)
+ ip connessione attuale
+ user agent connessione attuale
+ token attuale

Poi quando l'utente esegue login :

1- recuperi e controlli user e pwd dell'utente
2- salvi in sessione tutti i dati dell'utente
4- generi il token di controllo
3- aggiorni il database con i dati di ip user agent etc...


La procedura di controllo sessione recupera i dati dalla request
ip user agent session id etc etc....
A questo punto generi il crc dai dati della request e puoi eseguire tutti i controlli
che vuoi. Al cambiamento anche di 1 solo parametro che dipende da user agent, ip
cod sync o altro ..... blocchi tutto e distruggi la sessione .

Ci sono cmq anche altri modi ad esempio non salvare il token attuale in db ma generarlo al volo in query con le funzioni sql .. quindi se cambi un par in database la sessione di blocca in auto.

Poi vedi te ma considera sempre bene i contesti cosa devono fare e come devono interagire in base sempre a cosa gesticono