¿Debo evitar este esquema de autenticación basado en token (que no es OAuth)?

7

He tratado con OAuth antes, pero no estoy muy seguro acerca de la API con la que estoy trabajando ahora. Mi pregunta es básicamente: ¿esto es terriblemente inseguro ?

Como lo entiendo, oAuth hace lo siguiente (aproximadamente):

  1. Service X me da una clave y un secreto

  2. Le pido al usuario que me conceda acceso al servicio X

  3. Envié mi clave y mi secreto al Servicio X para verificar. Service X me da un token de solicitud, que envío con el usuario.

  4. El usuario confirma que quiere dejarme entrar, y el servicio me los envía con un token que puedo mantener en mi base de datos, y que utilizo para hacer llamadas de API de servicio en su nombre

  5. En algún momento, el token caduca, pero el servicio sabe quién soy, por lo que puedo pedirles una nueva

Sin embargo, la API con la que estoy tratando funciona de esta manera (todo https, obv):

  1. Me dan una clave de API.

  2. El usuario me da su nombre de usuario y contraseña

  3. Los transmito al servicio junto con mi clave de API y luego los descarto

  4. El servicio me envía un token que puedo usar para hacer llamadas de API en su nombre (usando el token y mi clave de API), que almaceno en mi base de datos.

  5. En algún momento, el token caduca y necesito obtener uno nuevo, por lo que el usuario debe volver a autenticarse.

¿Tengo razón al pensar que las principales debilidades de este esquema en comparación con OAuth son las siguientes?

  • no hay ninguna garantía de que la solicitud provenga de mi servidor, por lo que si alguien se rompió en mi base de datos, podría hacer llamadas a la API a voluntad de todos mis usuarios, usando mi clave de API, que podrían obtener al analizar el POST que tengo para enviar al autenticar un usuario dado
  • Tengo que volver a autenticar al usuario con una contraseña, etc., ya que básicamente es peligroso tener esa información flotando alrededor
  • Estoy obligado a proporcionar una conexión HTTPS para que el usuario escriba su contraseña de servicio en primer lugar

No son cosas de vida o muerte, no son cuentas bancarias de la gente, etc., pero sería bueno tener la confianza razonable de que no habrá una ficha de datos de Exxon Valdez.

Gracias por cualquier ayuda o consejo.

    
pregunta djb 13.09.2012 - 09:32
fuente

2 respuestas

4

Esto inicialmente me llama la atención: "El usuario me da su nombre de usuario y contraseña"

Con su nombre de usuario y contraseña puedes hacer mucho daño. Con OAuth es más fácil tener un control granular de acceso.

    
respondido por el rox0r 13.09.2012 - 18:31
fuente
2

Mi principal preocupación es tener que manejar el nombre de usuario y la contraseña del usuario. No estoy seguro de ver cómo difieren realmente los tokens. OAuth ofrece la posibilidad adicional de que su información se registre en el servicio para que pueda volver a autenticarse en el futuro, pero en última instancia, si su base de datos se ve comprometida, es probable que sus claves de API también lo estén. En ese caso, el token seguiría siendo útil para un atacante hasta su vencimiento, pero no tendrían la capacidad de obtener uno nuevo bajo el segundo sistema.

Funcionalmente, dependiendo de cómo funcione el almacenamiento de claves, podría haber una pequeña ventaja para OAuth, pero en realidad, la principal diferencia significativa es tener que enviar las credenciales usted mismo.

    
respondido por el AJ Henderson 13.09.2012 - 20:37
fuente

Lea otras preguntas en las etiquetas