Cómo hacer un token de usuario y dónde almacenarlo (lado del servidor)

Estos tokens de usuario que necesita sonar como cookies ;-)

El manejo de cookies es un tema delicado y hay varios enfoques.

Una habitual es una simple cadena de caracteres aleatoria. El usuario lo mantiene y usted lo valida contra un hash en su base de datos. Filtrar esta cadena sería muy malo, ten cuidado.

Hay una variación común de esta: en lugar de una cadena aleatoria, codifique el ID de usuario y otros datos de sesión y fírmela (criptográficamente), cuando el usuario presente, valide la firma y use los datos de la cookie. Esto te ahorra un viaje a la base de datos.

Uno de mis favoritos para clientes nativos: tokens HMAC. Compartes una clave secreta con el cliente. El cliente utiliza esta clave para marcar un nonce y una marca de tiempo y envía el hash, el nonce y la marca de tiempo al servidor. El servidor realiza los mismos cálculos para validar el valor recibido por el cliente.

De esta manera, el secreto se envía por el cable solo una vez, lo que reduce el riesgo de fugas. Bien implementado, también reduce el riesgo de ataques de repetición.

Hay otros. Tal vez tu framework ya sea compatible con uno de ellos, en ese caso podrías estar mejor con él.

Evalúe las diferentes alternativas y si necesita ayuda para decidir, consúltenos.

Las palabras mágicas que desea ver son OAuth2 y / o OpenID: OpenID es realmente lo que está buscando, ya que está enfocado en la autenticación (quién es este usuario), en lugar de la autorización (qué puede hacer este usuario) como es OAuth. Muchas personas usan OAuth para la autenticación (solicitando al proveedor de OAuth una dirección de correo electrónico, por ejemplo, y usándola). Ambos funcionan proporcionando un token de vuelta, con un vencimiento adecuado y así sucesivamente.

Al utilizar un estándar, de repente tienes una buena opción: ¿por qué hacer un seguimiento de los usuarios, las contraseñas y esas cosas? Es DIFÍCIL hacerlo de manera segura, lo convierte en un objetivo, agrega muchas funciones que necesita: caducidad, bloqueo, reinicio. ¿Por qué no omitir todo eso y simplemente usar un proveedor de OpenID / OAuth como Facebook, Twitter o Google? Eso es todo lo que 've con Facebook' que ve en las aplicaciones: hace que la vida de todos sea más fácil. Los usuarios no necesitan inventar otra contraseña estúpida y no tiene que preocuparse por almacenarla.

Si no quiere hacer eso (por alguna razón), aún puede aprovechar los estándares; simplemente haga de su servidor un proveedor de identidad OpenID y use su esquema para tokens, etc.