¿concesión de contraseña sin secreto de cliente?

7

Estoy luchando para decidir qué hacer para obtener un token de acceso desde una aplicación móvil.

Estoy seguro de que esto se ha cubierto antes, pero no puedo encontrarlo.

He habilitado la concesión de credenciales de propietario de recursos en mi servidor oauth2. La concesión requiere la identificación del cliente, el secreto y el nombre de usuario y la contraseña de un usuario.

Si no quiero almacenar el secreto de mi cliente en mi aplicación móvil, ¿es seguro enviar SOLAMENTE la identificación del cliente y emitir un token de acceso si el valor de la identificación del cliente almacenado en el registro del usuario coincide con la identificación del cliente enviada desde una aplicación móvil? ?

¿Cuál es la mejor práctica para este caso de uso?

    
pregunta Moon 06.10.2015 - 10:55
fuente

2 respuestas

3

Hay varios problemas con lo que intentas hacer ...

Información general

OAuth2 en la forma "tradicional" no debe utilizarse en ningún otro sitio que no sea un navegador web. Esto significa que si tiene una aplicación de escritorio o una aplicación móvil, no debe usar OAuth2 "tradicional" para la autenticación. Por "tradicional", me refiero a aquella en la que se le redirige al sitio web del proveedor para ingresar su nombre de usuario / contraseña y luego se le redirige nuevamente con un token que será utilizado por el cliente y etc.

Ahora comencemos la explicación ... La documentación de OAuth2 puede ser un poco confusa al principio. A lo que se refieren como cliente es a lo que generalmente llamamos servidor cuando estamos desarrollando una aplicación web. Hay 3 partes de OAuth2:

  1. Proveedor de servicios: Google, Facebook, etc.
  2. Cliente (servidor web, aplicación de escritorio, aplicación móvil que se comunica con el proveedor de servicios)
  3. Usuario (la aplicación que usa el usuario físico)

El problema con la aplicación móvil y de escritorio es que el cliente y el usuario son lo mismo Y residen en la máquina cliente. ¿Alguna vez escuchó el dicho "no hay lado del cliente de seguridad"? Esto se aplica bastante aquí.

Problema 1: el secreto del cliente

Tienes razón al no querer poner tu secreto de cliente en la aplicación móvil porque tu aplicación se puede "descompilar" y el pirata informático recuperará tu secreto de cliente. Una vez que lo tienen, pueden crear su propia aplicación y hacerse pasar por su aplicación.

Problema 2: nombre de usuario / contraseña

No utilice el OAuth2 "tradicional" en una aplicación móvil / de escritorio. El problema aquí es cómo se ingresa el nombre de usuario / contraseña y cómo se recupera el token que el proveedor de servicios le da al usuario después de iniciar sesión. Veamos la posible forma de que "funcione de manera segura" ...

Fallo de intento 1 : pídale a su usuario que ingrese su nombre de usuario / contraseña directamente a través de su interfaz.
Motivo de maldad : Felicitaciones, acaba de robar el inicio de sesión de Facebook de todos tus usuarios.

Fallo de intento 2 : abra un navegador con la página del proveedor.
Motivo de la falla : ¿Cómo recupera el token del navegador ahora? No hay forma de obtenerlo (a menos que tenga una aplicación maliciosa que lea constantemente lo que se encuentra en el navegador del usuario)

Fallo de intento 3 : abra un navegador falso para atraer al usuario y darle información de inicio de sesión.
Motivo de la falla : lo mismo en el intento # 1 . La aplicación móvil puede ir a pantalla completa y controlar todo lo que ve, por lo que no puede confiar en ellos. La aplicación de escritorio puede abrir una nueva ventana que podría imitar su navegador, etc.

El hecho difícil es que no hay manera de hacer que el OAuth2 "tradicional" funcione sin un navegador web seguro que actúe como "usuario" y un servidor web https que actúe como "cliente".

OAuth2 nunca se diseñó para proporcionar autenticación, sino simplemente autorización. Hay una gran distinción entre los dos. El protocolo OAuth2 fue "pirateado" para que también sea capaz de proporcionar autenticación (ver OpenId). El único problema con este "hack" es que solo funciona en el navegador web como se explicó anteriormente.

Una solución real

Si aún desea continuar utilizando OAuth2 / OpenID para su inicio de sesión y quiere hacerlo de forma segura, será un poco diferente de lo que ha imaginado. El uso de OAuth2 para iniciar sesión sigue siendo una buena idea, ya que les ahorra a los usuarios la molestia de recordar otro nombre de usuario / contraseña.

  1. Necesitará un servidor donde se almacenarán su identificación de cliente y su secreto. Su aplicación móvil se conectará a este servidor para enviar el token.

  2. Cuando solicite iniciar sesión, redirija al usuario a la página web del proveedor de servicios en un navegador. Alternativamente, el usuario podría ir directamente a su sitio web https para iniciar sesión, lo que nuevamente los redireccionará. La página web del proveedor de servicios es el único lugar donde debe ingresar su información de inicio de sesión.

  3. Cree una página web https donde el usuario podrá ver el token una vez que inicie sesión utilizando el proveedor de servicios.

  4. Pida al usuario que copie este token en su aplicación. Su aplicación luego enviará el token a su servidor. El servidor agrega el ID del cliente y el secreto del cliente y lo reenvía al proveedor de servicios.

Su usuario ahora puede usar su inicio de sesión "facebook" para iniciar sesión en su aplicación y no hay forma de que su aplicación robe su información de inicio de sesión o que un pirata informático robe el secreto de su cliente.

Nota adicional

El caso de ataques de phishing y OAuth2 cuando se usa fuera de un navegador web también es interesante, pero ese sería el tema de otra pregunta.

    
respondido por el Gudradain 06.10.2015 - 21:18
fuente
-1

Creo que hay una conversación relevante aquí enlace pero en realidad no es un respuesta a la cuestión.

Si le preocupa no codificar el secreto en la aplicación y, por lo tanto, tiene problemas con la recompilación, una solución puede ser usar un servidor secundario para almacenar de manera segura el secreto que puede descargarse con un nombre de usuario / contraseña diferente. que le pidas al usuario, es decir, el flujo va:

  1. pide al usuario que proporcione un nombre de usuario y / o contraseña

  2. use esas credenciales para iniciar sesión en un servicio seguro que devuelva el secreto

  3. use el secreto según lo previsto (¡no almacene localmente!)

Es mucho más trabajo y administración, pero proporciona una solución segura al problema secreto codificado.

    
respondido por el David Scholefield 06.10.2015 - 11:42
fuente

Lea otras preguntas en las etiquetas