¿Puede OAuth2 ayudar a autenticar la aplicación?

4

Tenemos una aplicación móvil que se comunica con nuestro servidor a través de una API HTTPS RESTful. También tenemos un atacante que pretende ser nuestra aplicación al intentar comunicarnos con nuestra API de servicios web.

Suponemos que nuestra aplicación en la naturaleza se puede diseñar por ingeniería inversa para obtener cualquier clave API, secretos compartidos, claves privadas, etc.

Mi pregunta es: ¿Puede OAuth2 ayudar a autenticar la aplicación ? No estoy preguntando acerca de la autenticación de la persona. No se trata de la seguridad de la aplicación móvil. Tenemos que asumir que la aplicación móvil puede verse comprometida.

En otras palabras, en el lado del servidor , ¿cómo distingo entre una solicitud legítima proveniente de nuestra aplicación y un atacante que pretende ser la aplicación?

Se ha sugerido que OAuth2 ayudará. No creo que este sea el caso. No creo que OAuth2 sea relevante para el problema que estoy describiendo.

Miré el Subvención implícita RFC 6749 . Para estar seguro, no requiere un secreto de cliente. Pero todo el punto es iniciar sesión en un lugar y usar esa autorización en otro lugar. Ya lo hacemos a través de nuestra propia API. No intentamos una especie de OpenID Connect, solo protegemos nuestra API de los atacantes.

¿Puede alguien confirmar que OAuth2 no nos ayuda, desde el lado de servidor de la ecuación? O, si me equivoco, ¡por favor explique!

    
pregunta Edward Barnard 14.09.2015 - 20:36
fuente

3 respuestas

1

¿Tiene una clave de consumidor y un secreto de consumidor entregado a las aplicaciones? Si lo hace, puede deshabilitar el acceso a las claves comprometidas y deshabilitar el acceso. La administración de claves API se puede hacer sin OAuth2. Pero el uso de OAuth2 le permitiría combinar la administración de claves y utilizar diferentes proveedores de autenticación. Para detectar qué claves están en peligro, necesitará análisis de API o informes de uso. OAuth2 no viene con un proveedor de autenticación. Asegurar su API contra los atacantes requiere un enfoque integral. Yo sugeriría comenzar con la administración de claves de la API y luego ver OAuth2 junto con el proveedor de autenticación.

    
respondido por el Vineet Bhatia 14.09.2015 - 21:08
fuente
1

Estoy de acuerdo en que OAuth2 es un marco de autorización, y la autenticación debe considerarse para la seguridad total. Le sugiero que consulte el registro de dispositivos y la fijación de certificados, para lograr la "trinidad" del registro de dispositivos móviles (ID de usuario, ID de dispositivo y certificado válido). Puede agregar la autenticación multifactor paso a paso basada en "riesgo" (OTP, SMS) basada en la geolocalización, o revocar el certificado del dispositivo para bloquear a un mal actor.

    
respondido por el Aric Day 24.09.2015 - 16:37
fuente
1

Algunos pensamientos adicionales. En una aplicación móvil, creo que debemos considerar 3 identidades

  1. Usuarios: normalmente se controlan mediante el token OAuth después de la autenticación inicial para eliminarlos.
  2. ID de la aplicación: esta es básicamente la aplicación que intenta realizar la operación en nombre del usuario. Es importante mantener esta identidad separada del usuario para asegurarse de que puede realizar un seguimiento, habilitar y deshabilitar el acceso a una aplicación en particular en función de diversos escenarios Y también puede ayudarlo con la facturación y el seguimiento. Como se sugirió, la administración de claves API sería la mejor manera de avanzar.
  3. ID del dispositivo: esto está ligado al usuario, pero en caso de que admita a varios usuarios en el mismo dispositivo, sería útil contar con esta información. Además de eso, una gran cantidad de comportamientos / métodos de autenticación basados en riesgo utilizarían esta información. La ID del dispositivo debe ser algo que se genere durante la configuración inicial y se registre como parte del inicio de sesión / conectividad inicial.
respondido por el jhash 28.09.2015 - 20:32
fuente

Lea otras preguntas en las etiquetas