En el proyecto en el que estoy trabajando actualmente, autentificamos el Clientes por nombre de usuario y contraseña. En este sistema, cada usuario tiene una clave que se calcula a partir de su contraseña.
Sin embargo, queremos proporcionar un acceso a la API para los usuarios en los que estarán Autenticado con un token jurado 2.0. Entonces, el problema que estoy enfrentando es que necesitamos la contraseña para calcular la clave y queremos evitar que el usuario codifique su contraseña. Entonces, lo que hemos pensado es que cuando el usuario solicita el token y el servidor cifra y firma la clave del usuario y la envía de vuelta al usuario junto con el token. En cada solicitud de API el usuario tiene que enviar ambos! Teniendo en cuenta que todas las comunicaciones se realizan a través de HTTPS, siempre existe la posibilidad de que haya un ataque del lado del cliente en el que el atacante pueda capturar tanto la clave cifrada como el token y reproducirlas utilizando las mismas llamadas de API.
La solución que se me ocurrió es la siguiente:
¡La clave cifrada debe contener una fecha de caducidad (esta fecha también debe incluirse en la firma)! El problema que queda aquí es cómo actualizaremos la clave cifrada si asumimos que el usuario no se conectará durante un período prolongado. Por otra parte, para evitar el rechazo y la prevención de ataques de repetición, solicitamos la firma del lado del cliente (utilizando HMAC o RSA) sobre el token y la contraseña cifrada.
Entonces, mi pregunta aquí es si pedirle al usuario que firme el token y la contraseña cifrada es demasiado e innecesario.
Gracias