El patrón básico que describe es básicamente la forma más sencilla de crear un sistema de administración de sesiones con estado. Sus usuarios obtendrían un token de sesión opaco (una cadena aleatoria segura de al menos 128 bits de longitud), generalmente establecido en una cookie de marca segura. Por lo general, luego tendrá una tabla que almacena Sesiones activas, con el token de sesión como la clave principal y las claves externas apuntando a su tabla de Usuarios (más cualquier metadato necesario, como los datos de caducidad de la sesión; de distancia cuando se supone que debe). Esto es, por supuesto, asumiendo que no solo puede almacenar las sesiones en la memoria (quizás son muy longevas, o necesitan ser almacenadas en servidores), y tiene un impacto sustancial en el rendimiento (muchas llamadas de base de datos), por lo general utilizarías mucho caché.
Si desea usar este modelo pero evita que un atacante que lea con éxito su tabla de Sesión se haga pasar por las sesiones activas, puede hacerlo ejecutando cada Token a través de una función hash (como SHA-256 *) antes de almacenarlo. La base de datos (o buscándola en la base de datos). Eso hace que sea posible verificar rápidamente un token determinado en la base de datos, pero hace que sea prácticamente imposible pasar de ver la base de datos a conocer los tokens válidos.
* Está bien usar un hash rápido aquí (a diferencia de las contraseñas), porque la cadena de entrada ya es una entropía demasiado alta para que un atacante la busque por fuerza bruta. De manera similar, no necesita sal (aunque agregar uno no dañará nada excepto algún rendimiento) porque 2 ^ 128 es un número demasiado grande para una tabla de arco iris.