¿Es OAuth en un teléfono móvil usando un servidor proxy demasiado problema?

He pasado los últimos días obteniendo una implementación de OAuth en funcionamiento. No en Android, sino en mi servidor web que actuará como el proxy del servicio protegido por OAuth. Estoy a punto de poner en práctica mi cliente Android y mi cabeza sigue siendo agitación sobre los problemas de seguridad e implementación.

OAuth es bastante desordenado cuando el cliente es sólo un navegador web. Tiene la siguiente serie de pasos:

  • (Navegador web del cliente) hacer solicitud a mi servidor proxy
  • (Servidor proxy) solicita un token no autorizado del proveedor de OAuth (por ejemplo, API de servicio web)
  • (Servidor proxy) pida al proveedor de OAuth que el usuario autorice el token. Redirigir el navegador web al URI del 'autorizar' del proveedor de OAuth
  • (Proveedor de OAuth) después de que el usuario complete la autorización, redirecciona el navegador a su URI de devolución de llamada
  • (Proxy server :: callback URI) Token de autorización de Exchange para un token de acceso y luego almacenarlo para futuras llamadas
  • Realizar llamadas API al proveedor de OAuth y devolver el documento de respuesta al navegador web del cliente

Ahora es bastante como es. Pero cuando se utiliza la misma mecánica con una aplicación móvil como un cliente que se involucra aún más. El problema es, por supuesto, que tienes que hacer algunas acrobacias para inyectar una sesión de navegador en el flujo de código de tu aplicación móvil mientras realizas la danza de OAuth. Esto significa que usted tiene que complicar aún más la danza OAuth de la siguiente manera (estoy usando una aplicación de Android para este ejemplo para hacer las cosas concretas):

  • (Aplicación web móvil :: código nativo) hacer solicitud desde el servidor proxy mediante Java / HTTP
  • (Servidor proxy) solicita un token no autorizado del proveedor de OAuth (por ejemplo, API de servicio web)
  • (Servidor proxy) devuelve un documento de respuesta a la aplicación web móvil que contiene el URI de redireccionamiento para la autorización del usuario por el proveedor de OAuth, de preferencia ocultos para ocultar la clave del consumidor y otros detalles para disuadir a "espiar" al aire.
  • (Aplicación web para móviles) Inicie una actividad del navegador web con la URL de autorización con un filtro de intenciones instalado. Sin embargo, almacene y reemplace el URI de retorno de llamada especificado del servidor proxy con un URI especial "falso" diseñado para una fácil identificación de URI mediante un filtro de intenciones (consulte los pasos siguientes)
  • (Proveedor de OAuth) después de que el usuario complete la autorización, redirigir el navegador a su URI de retorno de llamada "falso".
  • (Aplicación web para móviles) El filtro de intenciones detecta el URI de retorno de llamada "falso" y usa esa señal para recuperar el control. Reconstruya el URI de retorno de llamada del servidor proxy y utilice Java / HTTP para ejecutar la solicitud.
  • (Proxy server :: callback URI) Token de autorización de Exchange para un token de acceso y luego almacenarlo para futuras llamadas como antes
  • Realizar llamadas API al proveedor de OAuth y devolver el documento de respuesta a la aplicación web para móviles

Esto es bastante horrible como puedes ver. Si hay una forma mucho más simple de hacer esto, entonces estoy ansioso por escucharlo. Por lo que sé hay sólo dos alternativas, cada uno con sus propios problemas significativos.

1) Olvídate de un servidor proxy y hazlo todo directamente desde la aplicación web para móviles. El gran agujero de seguridad aquí es que usted tiene que "hornear" en su clave de consumidor OAuth y secreto en su aplicación. Si un atacante descompila su código y busca esas cadenas, una operación bastante fácil para alguien que tiene experiencia en ingeniería inversa, pueden causar estragos en su aplicación y en sus usuarios.

2) Cambie a XAuth donde el usuario le proporciona su nombre de usuario y contraseña y "acepta" no almacenarlos y cambiarlos directamente por un token de acceso con el servidor XAuth. El primer problema es ganar la confianza del usuario para proporcionar esa información, el problema OAuth fue creado para resolver, y por supuesto ¿qué pasa con las personas que no cumplen su compromiso de descartar los detalles de inicio de sesión? Peor aún, el servidor XAuth debe soportar XAuth y ofrecer conexiones HTTPS (SSL) y he visto toneladas de API web que no soportan tampoco. Una conexión SSL es necesaria, por supuesto, porque sin ella se envía el nombre de inicio de sesión y la contraseña del usuario a través del cable en texto plano al hacer su solicitud de XAuth.

Http://blog.zyber17.com/post/1283741364/why-xauth-is-a-really-dumb-idea

FYI, aunque no utiliza un servidor proxy el siguiente ejemplo ilustra la técnica que he descrito anteriormente para inyectar una sesión de navegador en su aplicación móvil OAuth interacción e interceptar el retorno de llamada URI:

Http://blog.doityourselfandroid.com/2010/11/10/oauth-flow-in-android-app/

Por lo tanto, parece bastante feo cualquier forma de mirarla y ni siquiera entrar en la molestia adicional de la creación y gestión de su propio ID de usuario para el usuario para que pueda buscar sus fichas de acceso almacenados en su servidor web proxy correctamente (incluyendo El desorden de un PIN más o código de acceso para que el usuario pueda administrar).

Nota interesante: Al hacer algunas investigaciones sobre una seguridad de la sesión del navegador web de Android, me complace descubrir que no se permite el acceso a la página web HTML actual. Si pudiera acceder a él, entonces un codificador Android hostil podría olfatear fácilmente el inicio de sesión y la contraseña del usuario, con lo que derrotó completamente el propósito y la intención de OAuth. Estaba consternado al descubrir que puede haber una forma de obtener ese HTML a través del objeto CacheManager. Curiosamente, el objeto está ahora en desuso y el calendario de eliminación de acuerdo con los documentos Android, por lo que espero que eso significa que Google descubrió el agujero de seguridad (potencial) y está tomando medidas para eliminarlo en una próxima compilación:

Http://developer.android.com/reference/android/webkit/CacheManager.html

Para terminar, me gustaría escuchar los pensamientos de aquellos que han luchado con estos mismos problemas al crear sus aplicaciones OAuth.

Roschler

    Janrain ha lanzado una biblioteca que proporciona un poco de pegamento de la interfaz de usuario y un sistema de inicio de sesión de proxy; Es compatible con un montón de proveedores de identidad de OAuth populares (por ejemplo, Google / FB). Al final del flujo de entrada recibes un HTTPS POST desde el dispositivo que te proporciona un token intercambiable para un identificador de usuario y otra información, y un canal para devolver un token de acceso al dispositivo.

    http://www.janrain.com/products/engage/mobile

    https://github.com/janrain/engage.android

    Divulgación: Trabajo en Janrain, en esta biblioteca.

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.