Stai confrontando arance e mele qui, o più esattamente, mattoni e case. Ciò che identifica una conversazione è per definizione una sessione. Punto. Ma la sessione può essere implementata in vari modi:
- dati lato server e un ID sessione memorizzati in un cookie (il modo più comune al giorno d'oggi)
- dati lato server e un ID sessione trasportati come parametro URL (usato per essere comune quando gli utenti rifiutavano i cookie)
- dati memorizzati in un cookie (limitato a 4k) - utilizza meno risorse del server
- forse altri ...
Non tutti i framework consentono tutte le implementazioni di sessione.
Tornando alla tua domanda, dal punto di vista della sicurezza, i dati che non lasciano il server dovrebbero essere più difficili da manomettere, perché è banale creare un cookie personalizzato attraverso qualsiasi libreria client HTTP. Pertanto, dovresti almeno firmare il cookie e controllare la firma su ogni pass, e se non vuoi perdere i dati interni dall'applicazione, devi anche crittografare il contenuto dei cookie. Questo, e la limitazione aggiunta di 4k per una dimensione del cookie, è sufficiente a spiegare perché i dati di sessione sono generalmente tenuti lato server con solo un ID passato in un cookie.
TL / DR: a meno che tu non abbia una valida ragione per non farlo, il mio consiglio sarebbe quello di attenersi all'utilizzo comune e memorizzare l'id utente in una sessione lato server: questo è probabilmente il modo predefinito per il tuo framework .. .
Risposta dettagliata:
What's the difference between storing in one versus the other for the authentication purpose?
Nessuna differenza su un punto di vista funzionale perché entrambe sono implementazioni differenti di una sessione
Which is more secure? Why?
L'uso di una sessione è più sicuro perché si baserà su una struttura o una libreria pesantemente testata. La sessione lato server è più affidabile perché le sessioni di cookie si basano su chiavi aggiuntive per la firma e / o la crittografia e la gestione delle chiavi è un ulteriore punto da considerare in un punto di vista della sicurezza
What's recommended?
Sicuramente la sessione, perché è fornita dalla tua struttura o libreria, e la maggior parte dei problemi di sicurezza derivano dall'implementazione. Questo è il motivo per cui le best practice sulla sicurezza consigliano non eseguire il rollover
What should I pay attention to when doing so?
Non puoi fare affidamento su ciò che non controlli, quindi non puoi aspettarti che un cookie non sia stato manomesso dal lato client. Quindi deve firmare il cookie a livello di applicazione con una chiave gestita in modo sicuro e sicuro. L'ID utente interno normalmente non è rilevante per il client, quindi è necessario crittografarlo ancora a livello di applicazione e comunque con una chiave gestita in modo sicuro e sicuro. È necessario aggiungere controlli aggiuntivi, sempre a livello di applicazione, per assicurarsi che il cookie (anche firmato e crittografato) non sia stato spiato da una sessione precedente legittima, quindi è necessario almeno memorizzare l'ID di sessione all'interno del tuo specifico cookie firmato. E potrebbero esserci altri possibili problemi a cui non ho pensato ...