Asegure el flujo de OAuth 2 para el lado del cliente o la aplicación móvil

Navega tus respuestas
6

Estoy implementando una API y una aplicación web del lado del cliente, y se supone que deben comunicarse a través de una API y usar OAuth 2 para la autenticación.

No puedo superar mi confusión sobre cuál es la forma correcta de autenticar a los usuarios (es decir, sin grandes descuidos de seguridad).

Reuní lo siguiente:

  • Idealmente, debería exponer un formulario web en el servidor API que toma el nombre de usuario y la contraseña y los redirige con un código de autorización, que se intercambiará del lado del cliente por un token de acceso al token de acceso.
  • El enfoque que describí se considera engorroso, por lo que OAuth 2 ofrece un flujo implícito en el que la aplicación del lado del cliente realiza una solicitud que contiene un client_id y las credenciales del usuario, que recopila. Recibe un token de acceso.
  • Los kits de herramientas de autenticación parecen desconfiar de permitir que solo se pase client_id y, en cambio, requiere que se incluya client_secret .
  • Según el punto anterior, como desarrollador puede que tenga que incrustar su client_secret en la aplicación distribuible, por lo tanto, hacerla pública.
  • Algunos colegas que comprenden OAuth 2 me dijeron que no es raro que los desarrolladores incluyan client_secret en sus distribuibles, y que algunos servicios de alto perfil (supuestamente Twitter) también lo hacen.
  • Si agrega un proxy entre el cliente y el servidor OAuth 2 para agregar el client_secret a las solicitudes, no mejora la seguridad ya que es similar a ignorar el client_secret por completo.
  • La única preocupación de seguridad que puedo encontrar relacionada con la incrustación de client_id y client_secret en el cliente es que un atacante puede implementar su propio cliente que, cuando se le dan credenciales de usuario, puede actuar en nombre del usuario. Esto no parece un ataque probable, ya que el phishing es similar y produce mayores beneficios.

Las siguientes preguntas aún no han sido respondidas para mí:

  1. ¿Cuál es la diferencia entre el flujo de credenciales del cliente y el flujo de contraseña del propietario del recurso ? ¿Cuál debería preferir? Las respuestas a esta pregunta do No me des una clara comprensión de la diferencia.
  2. ¿Hay algún problema de seguridad importante con el uso del flujo implícito o es viable?
  3. ¿Es seguro incrustar client_secret ?
    • Si no, ¿cuál es la alternativa? ¿Debo seguir solicitando client_id o permitir el uso de clientes "públicos" (no registrados)?
pregunta Gabriele Cirulli 31.07.2016 - 13:07
fuente

2 respuestas

1

Primero, dejemos una cosa clara: OAuth2 es la autorización, así que ten esto en cuenta.

A continuación, intentemos definir más las cosas:

Propietario del recurso

Estas son las credenciales que utiliza cuando desea otorgar acceso a algo como Snapchat que desea iniciar sesión a través de FB.

Credenciales del cliente

Estas son las credenciales que identifican a un cliente, por ejemplo, una aplicación moblie o una aplicación en los navegadores. Por ejemplo, no puede utilizar el acceso a Snapchat aprobado con el acceso a Instantgram aprobado.

Ejemplo

  • Inicia sesión en Snapchat a través de FB.
  • Se redirige a FB para autenticar y / o autorizar a Snapchat. La aplicación solicita una concesión de acceso para acceder a su recurso (Perfil I.E FB).
  • Usted aprueba y Snapchat envía la subvención a FB, que otorga Snapchat un token de acceso, que puede utilizar para acceder a su lista de amigos.

Preocupaciones de seguridad en torno al flujo implícito

Hay preocupaciones relevantes de seguridad acerca de. Puede verlo en aquí en SO y here en Thread Safe. En general, es una práctica viable y solo debe tener en cuenta algunas (lo que ya debería tener en cuenta) las mejores prácticas de seguridad.

Por último, a las claves incrustadas

Te sugiero que no lo hagas. Le dirijo a esta entrada de blog de stormpath sobre esta preocupación específica. Esto es principalmente alrededor de JWT pero se aplica a Oauth2.

    
respondido por el Shane Andrie 05.08.2016 - 01:11
fuente
1

No es seguro guardar el secreto del cliente en el móvil, así que trabajaré en la pregunta 3.

No tengo una solución, pero explicaré una alternativa que podría mitigar el riesgo de guardar un client_secret en un dispositivo móvil.

Una alternativa que puede hacer sería el uso de credenciales de instalación en lugar de las credenciales de cliente. Las credenciales del cliente tendrán una relación principal con las credenciales de instalación.

  

Credenciales de cliente 1
  Credenciales de instalación 1
  Credenciales de instalación 2   ....

La idea es usar un backend de canal de seguridad para backend para generar credenciales de instalación. Necesitará crear un servicio, donde recibirá las credenciales de una APLICACIÓN y devolverá una ID de instalación. Además, el propietario de la aplicación móvil deberá crear un servicio donde el usuario solicite una credencial de instalación.

Básicamente,

Aplicación móvil - > BackEnd (propiedad de aplicación móvil) - > BackEnd (propietario de OAuth)

Esta solución no resuelve su problema, pero mitiga el riesgo de exposición secreta. Obtendrá las credenciales de instalación y podrá usarlas en su flujo de OAuth. Si algunos obtienen el secreto, puede hacerse pasar por un solo usuario. El ataque no escalará.

    
respondido por el Oximer 04.08.2016 - 15:14
fuente

Lea otras preguntas en las etiquetas

JWT vs. certificados de cliente Vulnerabilidad de inyección de PHP SQL en las declaraciones UPDATE