He pasado los últimos días para conseguir una aplicación de OAuth en funcionamiento. No en Android, sino en mi servidor web que actuará como proxy del servicio protegido OAuth. Estoy a punto de implementar mi cliente de Android y mi cabeza todavía está agitada por cuestiones de seguridad e implementación.¿OAuth es demasiado problema para un teléfono móvil que utiliza un servidor proxy?
OAuth es bastante desordenado cuando el cliente es sólo un navegador web. Usted tiene la siguiente serie de pasos:
- (navegador web del cliente) hacer una petición con el servidor proxy
- (servidor proxy) petición de señal no autorizada del proveedor OAuth (por ejemplo - Web API del servicio)
- (Proxy servidor) solicite al proveedor de OAuth que el usuario autorice el token. Redirigir el navegador web a OAuth proveedor de 'autorizar' URI
- (proveedor de OAuth) después de usuario completa de autorización, redirige el navegador a su devolución de llamada URI
- (servidor proxy :: devolución de llamada URI) token de autorización de cambio de un token de acceso y luego almacenarla para las llamadas futuras
- llamadas a la API realice en proveedor de OAuth y volver documento de respuesta al cliente navegador web
Ahora que es más que suficiente, ya que es. Pero cuando se usa la misma mecánica con una aplicación móvil como cliente, se vuelve aún más complicado. 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 haces el baile de OAuth. Esto significa que tienes que complicar aún más la danza OAuth la siguiente manera (estoy usando una aplicación Android para este ejemplo para hacer las cosas de hormigón):
- (aplicación web para móviles :: código nativo) hacer una petición desde el servidor proxy utilizando Java/HTTP
- (servidor proxy) petición de señal no autorizada del proveedor OAuth (por ejemplo - web API del servicio)
- (servidor proxy) devolver un documento de respuesta a la aplicación web móvil que contiene el URI de redireccionamiento de autorización de usuario por el proveedor OAuth , preferiblemente ofuscado para ocultar la clave del consumidor y otros detalles para disuadir el "over-the-air" snooping.
- (aplicación web móvil) Poner en marcha una actividad del navegador web con la URL de autorización con un filtro instalado intención. Sin embargo, almacenar y luego vuelva a colocar devolución de llamada especificado por el servidor proxy URI con un especial de "falsa" URI elaborado para facilitar su identificación URI por un filtro de intención (véanse las siguientes Etapas)
- (proveedor de OAuth) después de usuario completa de autorización, redirigir el navegador a su " falso URI de devolución de llamada.
- (aplicación web móvil) detecta filtro de Intención "falsa" de devolución de llamada URI y utiliza esa señal para recuperar el control. Reconstruya el URI de devolución de llamada del servidor proxy y use Java/HTTP para ejecutar la solicitud.
- (servidor proxy :: devolución de llamada URI) token de autorización de cambio de un token de acceso y luego almacenarla para futuras llamadas como antes
- API realizar llamadas a proveedor de OAuth y volver documento de respuesta a la aplicación web para móviles
Esto es bastante horrible como puedes ver. Si hay una manera mucho más simple de hacerlo, estoy ansioso por escucharlo. Por lo que sé, solo hay otras dos alternativas, cada una con sus propios problemas significativos.
1) Olvídate de un servidor proxy y hacer todo directamente desde la aplicación web móvil.El gran problema de seguridad aquí es que tienes que "hornear" tu clave de consumidor de OAuth y el secreto en tu aplicación. Si un atacante descompila su código y busca esas cadenas, una operación bastante fácil para alguien con experiencia en ingeniería inversa, puede 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 e intercambiarlos 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 que OAuth fue creado para resolver y, por supuesto, ¿qué pasa con las personas que no respetan su compromiso de descartar los datos de inicio de sesión? Peor aún, el servidor XAuth debe ser compatible con XAuth y ofrecer conexiones HTTPS (SSL) y he visto toneladas de API web que tampoco son compatibles. Por supuesto, es necesaria una conexión SSL porque sin ella enviarías el nombre de usuario y la contraseña del usuario a través del cable en texto sin formato al hacer tu solicitud de XAuth.
http://blog.zyber17.com/post/1283741364/why-xauth-is-a-really-dumb-idea
su información, a pesar de que no utiliza un servidor proxy en el siguiente ejemplo ilustra la técnica que he descrito anteriormente para la inyección de una sesión del navegador en tu móvil interacción de aplicaciones OAuth e interceptar la devolución de llamada URI:
http://blog.doityourselfandroid.com/2010/11/10/oauth-flow-in-android-app/
Por lo tanto, parece bastante feo como se mire y ni siquiera me molestó más crear y administrar su propia identificación de usuario para que el usuario pueda buscar sus tokens de acceso almacenados en su web proxy servidor adecuadamente (incluido el desorden de un PIN o código de acceso más para que el usuario administre).
Nota al margen interesante: Cuando realicé algunas investigaciones sobre la seguridad de una sesión de un navegador web Android, me complació descubrir que no tiene permitido el acceso al HTML de la página web actual. Si pudieras acceder a él, un codificador hostil de Android podría olfatear fácilmente el nombre de usuario y la contraseña, derrotando por completo el propósito y la intención de OAuth. Me desanimé al descubrir que podría haber una manera de obtener ese HTML a través del objeto CacheManager. Curiosamente ese objeto ahora es obsoleto y un calendario para la eliminación de acuerdo con la documentación de Android por lo que es de esperar que significa que Google descubrió el agujero de seguridad (potencial) y está tomando medidas para eliminarlo en una próxima construcción:
http://developer.android.com/reference/android/webkit/CacheManager.html
En cerrando, me gustaría escuchar los pensamientos de aquellos que han tenido problemas con estos mismos problemas al crear sus aplicaciones OAuth.
- roschler