Won't necessarily be sent over SSL

Non esiste un modo sicuro per farlo affatto se questo è il caso. Risolvi questo problema e puoi scegliere tra client based sessions o server side sessions , ma i metodi BOTH richiederanno che i dati di sessione vengano inviati SEMPRE su SSL, altrimenti le sessioni non hanno valore.

Sessioni lato server

In un database comune a entrambi i backend impostare una voce in una tabella con un ID sessione univoco generato, dati di sessione e altri campi di manutenzione che sarebbero utili (tempo dell'ultima attività, ecc.)

La tabella dovrebbe essere simile alla seguente:

id ( text, 40, not null ), data ( jsonb ), lastCom ( timestamp )

Queste sessioni vengono spesso utilizzate perché senza uno speciale codice lato server una sessione può essere terminata da remoto semplicemente eliminando la voce della sessione nel database.

Sessioni lato client

Spesso usato perché con la corretta logica di invalidazione SSL e back-end questi sono GIUSTI quanto sicuri come sessioni lato server. Tuttavia, richiedono la logica back-end per invalidare le sessioni, altrimenti la sessione non è sicura perché non c'è un modo remoto per un amministratore di terminare la sessione. L'utente possiede il cookie, e solo perché ha fallito una volta non significa che non possono riprovare con gli stessi dati ESATTI. Questo perché TUTTA la manutenzione della sessione viene eseguita sul lato utente, quindi è ancora necessaria la convalida del server, ma non significa che sia necessario un database. Significa semplicemente che devi inviare un cookie aggiornato con ogni richiesta (modificando i dati di manutenzione all'interno, come un timestamp di validità)

Entrambi i metodi sono molto sicuri e possono essere implementati in vari modi (JWT, passaporto, ecc. ecc.), ma spetta a te scegliere il metodo che desideri. Ricorda, i dati della sessione devono SEMPRE essere inviati su SSL