Autenticación básica extendida

2

Me gustaría implementar una API REST con autenticación básica que se basa en el nombre de usuario y la contraseña. Debido a que REST no tiene estado, el usuario tendría que volver a ingresar el nombre de usuario y la contraseña para cada solicitud sin almacenarlos en una cookie. Como el almacenamiento de un nombre de usuario y contraseña en una cookie no es una opción, se necesita otra solución.

El escenario en el que estoy pensando será el siguiente:

  1. El usuario navega a enlace
  2. El usuario ingresa el nombre de usuario y la contraseña (cifrados con SSL).
  3. El sistema verifica si las credenciales proporcionadas son correctas.
  4. Si es correcto: el sistema genera un GUID, cifra el GUID con la contraseña del usuario y lo envía al usuario.
  5. Si no es correcto: aumentar FailedPasswordAttemptCounter y comprobar si el inicio de sesión debe estar bloqueado para el usuario.

Como la respuesta del servidor al cliente no está cifrada, el GUID se cifra con la contraseña del usuario. Solo el usuario puede descifrar el GUID.

El usuario proporciona el GUID para todos los demás recursos que necesitan autenticación en lugar de nombre de usuario y contraseña.

¿Este enfoque es mejor en comparación con el de proporcionar un nombre de usuario & ¿Contraseña para cada solicitud?

Soy consciente del hecho de que alguien puede generar GUID e intenta autenticarse con ellos. Pero un ataque dirigido a un usuario específico es casi imposible ya que el recurso de inicio de sesión proporciona un mecanismo de bloqueo.

Mi pregunta está relacionada de alguna manera con esta: enlace

    
pregunta niklr 03.08.2013 - 20:15
fuente

1 respuesta

4
  

Debido a que REST no tiene estado, el usuario tendría que volver a ingresar el nombre de usuario y la contraseña para cada solicitud

Es directamente contradictorio con

  

El usuario proporciona el GUID para todos los demás recursos que necesitan autenticación en lugar de nombre de usuario y contraseña.

Puedes:

A. enviar la contraseña con cada solicitud, o
  B. no envíe la contraseña con cada solicitud.

Pero tendrás que elegir uno.

Aquí está el escenario ideal. Está cerca de lo que estás describiendo:

  1. El usuario inicia sesión. Nombre de usuario, contraseña, token de autenticación, lo que sea.
  2. El servidor almacena ese servidor de eventos de autenticación y crea un token aleatorio (GUID o lo que quieras) para entregar al cliente
  3. Cuando el cliente desea enviar su solicitud, también envía el token que lo identifica al servidor. Podría estar en una cookie, en la URL, en una variable de formulario, en un encabezado separado. No importa Cualquier lugar en la solicitud está bien.
  4. El servidor caduca el token después de que ya no se debe utilizar. Quizás sea bueno por 5 minutos, tal vez sea bueno hasta que se haya usado para una operación. Quizás sea bueno hasta que quede no utilizado durante 5 minutos. Lo que quieras.
respondido por el tylerl 03.08.2013 - 22:18
fuente

Lea otras preguntas en las etiquetas