No se enviará necesariamente a través de SSL

NO hay una manera segura de hacer esto en absoluto si este es el caso. Arregla eso y tienes la opción de client based sessions o server side sessions , pero AMBOS métodos requerirán que los datos de la sesión solo se envíen SIEMPRE SSL, de lo contrario las sesiones no valen nada.

Sesiones del lado del servidor

En una base de datos común a ambos backends, configure una entrada en una tabla con un ID de sesión único generado, datos de sesión y otros campos de mantenimiento que serían útiles (tiempo de la última actividad, etc.)

La tabla debe tener el siguiente aspecto:

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

Estas sesiones se usan a menudo porque sin un código especial del lado del servidor, una sesión se puede terminar de forma remota simplemente eliminando la entrada de la sesión en la base de datos.

Sesiones del lado del cliente

A menudo se utiliza porque con la lógica de invalidación de SSL y backend adecuada, estos son tan seguros como las sesiones del lado del servidor. Sin embargo, requieren una lógica de back-end para invalidar las sesiones, de lo contrario, la sesión no es segura porque no hay una forma remota para que un administrador termine la sesión. El usuario es propietario de la cookie, y solo porque haya fallado una vez no significa que no pueda volver a intentar con los mismos datos EXACTOS. Esto se debe a que TODO el mantenimiento de la sesión se realiza en el lado del usuario, por lo que la validación del lado del servidor también es necesaria, pero no significa que necesite una base de datos. Solo significa que debe enviar una cookie actualizada con cada solicitud (cambio de los datos de mantenimiento en el interior, como una marca de tiempo de validez)

Ambos métodos son bastante seguros y se pueden implementar de muchas maneras (JWT, pasaporte, etc.), pero depende de usted elegir qué método desea hacer. Solo recuerda, los datos de la sesión solo deben enviarse NUNCA SSL