iphone - appauth - Secretos de OAuth en aplicaciones móviles
oauth redirect url (13)
Al usar el protocolo OAuth, necesita una cadena secreta obtenida del servicio al que desea delegar. Si está haciendo esto en una aplicación web, puede simplemente almacenar el secreto en su base de datos o en el sistema de archivos, pero ¿cuál es la mejor manera de manejarlo en una aplicación móvil (o una aplicación de escritorio para el caso)?
El almacenamiento de la cadena en la aplicación obviamente no es bueno, ya que alguien podría encontrarlo fácilmente y abusar de él.
Otro enfoque sería almacenarlo en su servidor, y hacer que la aplicación lo busque en cada ejecución, nunca almacenarlo en el teléfono. Esto es casi tan malo, porque debe incluir la URL en la aplicación.
La única solución factible que puedo encontrar es obtener primero el token de acceso como es normal (preferentemente usando una vista web dentro de la aplicación) y luego enrutar toda la comunicación a través de nuestro servidor, lo que agregaría el secreto a los datos de solicitud y la comunicación con el proveedor. Por otra parte, soy un novato de la seguridad, así que realmente me gustaría escuchar las opiniones de algunas personas conocedoras sobre esto. No me parece que la mayoría de las aplicaciones lleguen a estos extremos para garantizar la seguridad (por ejemplo, Facebook Connect parece suponer que usted pone el secreto en una cadena directamente en su aplicación).
Otra cosa: no creo que el secreto esté involucrado al solicitar inicialmente el token de acceso, por lo que podría hacerse sin involucrar a nuestro propio servidor. ¿Estoy en lo correcto?
Aquí hay algo en lo que pensar. Google ofrece dos métodos de OAuth ... para aplicaciones web, donde registra el dominio y genera una clave única, y para las aplicaciones instaladas donde usa la clave "anónimo".
Tal vez pasé por alto algo en la lectura, pero parece que compartir la clave única de su aplicación con una aplicación instalada es probablemente más seguro que usar "anónimo" en el método oficial de las aplicaciones instaladas.
Aquí he respondido la forma segura de almacenar su información de oAuth en la aplicación móvil
https://.com/a/17359809/998483
Como han mencionado otros, no debería haber ningún problema real al almacenar el secreto localmente en el dispositivo.
Además de eso, siempre puedes confiar en el modelo de seguridad basado en UNIX de Android: solo tu aplicación puede acceder a lo que escribes en el sistema de archivos. Simplemente escriba la información en el objeto SharedPreferences predeterminado de su aplicación.
Para obtener el secreto, uno debería obtener acceso raíz al teléfono Android.
Con OAUth 2.0, puede almacenar el secreto en el servidor. Use el servidor para adquirir un token de acceso que luego moverá a la aplicación y podrá realizar llamadas desde la aplicación al recurso directamente.
Con OAuth 1.0 (Twitter), se requiere el secreto para hacer llamadas a la API. Proxying llamadas a través del servidor es la única forma de garantizar que el secreto no se vea comprometido.
Ambos requieren algún mecanismo para que su componente de servidor sepa que es su cliente el que lo llama. Esto tiende a hacerse en la instalación y utilizando un mecanismo específico de la plataforma para obtener una identificación de aplicación de algún tipo en la llamada a su servidor.
(Soy el editor de la especificación OAuth 2.0)
Con OAuth 2.0 puede simplemente usar el flujo del lado del cliente para obtener un token de acceso y usar este token de acceso para autenticar todas las solicitudes adicionales. Entonces no necesitas un secreto en absoluto.
Una buena descripción de cómo implementar esto se puede encontrar aquí: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps
Estoy de acuerdo con Felixyz. OAuth, aunque es mejor que Basic Auth, todavía tiene un largo camino por recorrer para ser una buena solución para aplicaciones móviles. He estado jugando con el uso de OAuth para autenticar una aplicación de teléfono móvil en una aplicación de Google App Engine. El hecho de que no pueda administrar de forma confiable el secreto del consumidor en el dispositivo móvil significa que el uso predeterminado es el acceso ''anónimo''.
El paso de autorización del navegador de la aplicación Google App Engine OAuth lo lleva a una página donde contiene texto como: "El sitio <algún sitio> está solicitando acceso a su cuenta de Google para el producto (s) enumerados a continuación"
YourApp (yourapp.appspot.com) - no está afiliado a Google
etc
Toma <algún-sitio> del dominio / nombre de host utilizado en la url de devolución de llamada que usted proporciona, que puede ser cualquier cosa en el Android si usa un esquema personalizado para interceptar la devolución de llamada. Por lo tanto, si utiliza un acceso ''anónimo'' o si su secreto de consumidor se ve comprometido, cualquiera puede escribirle a un consumidor que engaña al usuario para que le dé acceso a su aplicación Gae.
La página de autorización de Google OAuth también contiene muchas advertencias que tienen 3 niveles de severidad dependiendo de si está usando claves ''anónimas'', secretas de consumidor o públicas.
Bastante aterrador para el usuario promedio que no es técnicamente inteligente. No espero tener un alto porcentaje de finalización de suscripción con ese tipo de cosas en el camino.
Esta publicación de blog aclara cómo los secretos de los consumidores no funcionan realmente con las aplicaciones instaladas. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/
Facebook no implementa OAuth estrictamente (todavía), pero han implementado una forma para que no incruste su secreto en su aplicación de iPhone: https://web.archive.org/web/20091223092924/http://wiki.developers.facebook.com/index.php/Session_Proxy
En cuanto a OAuth, sí, cuanto más lo pienso, estamos un poco llenos. Tal vez this lo arregle.
Hay una nueva extensión para el Tipo de concesión de código de autorización llamada Prueba clave para intercambio de código (PKCE) . Con eso, no necesitas un secreto de cliente.
PKCE (RFC 7636) es una técnica para proteger a clientes públicos que no usan un secreto de cliente.
Es utilizado principalmente por aplicaciones nativas y móviles, pero la técnica también se puede aplicar a cualquier cliente público. Requiere soporte adicional del servidor de autorización, por lo que solo es compatible con ciertos proveedores.
Para obtener más información, puede leer el RFC 7636 completo o esta breve introducción .
No tengo mucha experiencia con OAuth, pero no todas las solicitudes requieren no solo el token de acceso del usuario, sino también una clave de consumidor de la aplicación y un secreto. Por lo tanto, incluso si alguien roba un dispositivo móvil e intenta sacar datos de él, también necesitaría una clave de aplicación y un secreto para poder hacer cualquier cosa.
Siempre pensé que la intención detrás de OAuth era que todos los Tom, Dick y Harry que tuvieran un mashup no tuvieran que almacenar sus credenciales de Twitter en el claro. Creo que resuelve ese problema bastante bien a pesar de sus limitaciones. Además, en realidad no fue diseñado teniendo en cuenta el iPhone.
Sí, este es un problema con el diseño de OAuth al que nos enfrentamos. Optamos por realizar un proxy de todas las llamadas a través de nuestro propio servidor. OAuth no se descartó por completo con respecto a las aplicaciones de escritorio. No hay una solución perfecta para el problema que he encontrado sin cambiar OAuth.
Si lo piensas y haces la pregunta por qué tenemos secretos, es sobre todo para las aplicaciones de provisión y deshabilitación. Si nuestro secreto está en peligro, entonces el proveedor solo puede revocar la aplicación completa. Dado que tenemos que insertar nuestro secreto en la aplicación de escritorio, estamos tan equivocados.
La solución es tener un secreto diferente para cada aplicación de escritorio. OAuth no hace que este concepto sea fácil. Una forma es hacer que el usuario vaya y cree un secreto por su cuenta e ingrese la clave por su cuenta en su aplicación de escritorio (algunas aplicaciones de Facebook hicieron algo similar durante mucho tiempo, haciendo que el usuario vaya y cree Facebook para configurar sus tamaños personalizados y mierda). No es una gran experiencia para el usuario.
Estoy trabajando en la propuesta de un sistema de delegación para OAuth. El concepto es que usando nuestra propia clave secreta que obtenemos de nuestro proveedor, podemos emitir nuestro propio secreto delegado a nuestros propios clientes de escritorio (uno para cada aplicación de escritorio básicamente) y luego, durante el proceso de autenticación, enviamos esa clave al nivel superior proveedor que nos llama y vuelve a validar con nosotros. De esa forma, podemos revocar nuestros propios secretos que emitimos a cada cliente de escritorio. (Préstamo de una gran cantidad de cómo esto funciona desde SSL). Este sistema completo sería perfecto para los servicios web de valor agregado que transmiten las llamadas a un servicio web de terceros.
El proceso también podría realizarse sin devoluciones de verificación de delegación si el proveedor de nivel superior proporciona una API para generar y revocar nuevos secretos delegados. Facebook está haciendo algo similar al permitir que las aplicaciones de Facebook permitan a los usuarios crear sub-aplicaciones.
Hay algunas conversaciones sobre el tema en línea:
http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14
La solución de Twitter y Yammer es una solución de autenticación: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html
También estoy tratando de encontrar una solución para la autenticación móvil de OAuth y almacenar secretos dentro del paquete de aplicaciones en general.
Y una loca idea simplemente me golpeó: la idea más simple es almacenar el secreto dentro del binario, pero ofuscado de alguna manera, o, en otras palabras, almacenar un secreto encriptado. Entonces, eso significa que tienes que almacenar una clave para descifrar tu secreto, lo que parece que nos ha llevado a un círculo completo. Sin embargo, ¿por qué no utilizar una clave que ya está en el sistema operativo, es decir, está definida por el sistema operativo no por su aplicación.
Entonces, para aclarar mi idea, es que eliges una cadena definida por el sistema operativo, no importa cuál. Luego encripte su secreto usando esta cadena como la clave, y almacénelo en su aplicación. Luego, durante el tiempo de ejecución, descifrar la variable con la tecla, que es solo una constante del sistema operativo. Cualquier hacker que examine su binario verá una cadena encriptada, pero no una clave.
¿Eso funcionará?
Una solución podría ser codificar el secreto de OAuth en el código, pero no como una cadena simple. Ofuscarlo de alguna manera: dividirlo en segmentos, desplazar caracteres por un desplazamiento, rotarlo, hacer una o todas estas cosas. Un cracker puede analizar su código de bytes y buscar cadenas, pero el código de ofuscación puede ser difícil de descifrar.
No es una solución infalible, sino una solución barata.
Dependiendo del valor del exploit, algunos crackers genios pueden llegar a mayores distancias para encontrar su código secreto. Debe sopesar los factores: el costo de la solución del lado del servidor mencionada anteriormente, el incentivo para que los crackers gasten más esfuerzos en encontrar su código secreto y la complejidad de la ofuscación que puede implementar.
No almacene el secreto dentro de la aplicación.
Necesitas tener un servidor al que la aplicación pueda acceder mediante https (obviamente) y almacenar el secreto en él.
Cuando alguien desea iniciar sesión a través de su aplicación móvil / de escritorio, su aplicación simplemente reenviará la solicitud al servidor que luego anexará el secreto y lo enviará al proveedor del servicio. Su servidor puede decirle a su aplicación si fue exitosa o no.
Luego, si necesita obtener información confidencial del servicio (Facebook, Google, Twitter, etc.), la aplicación pregunta a su servidor y su servidor solo la dará a la aplicación si está conectada correctamente.
Realmente no hay otra opción que guardarla en un servidor. Nada en el lado del cliente es seguro.
Nota
Dicho esto, esto solo lo protegerá contra el cliente malicioso pero no contra el cliente malicioso y no contra otros clientes maliciosos (phising) ...
OAuth es un protocolo mucho mejor en el navegador que en el escritorio / dispositivo móvil.