Secretos de OAuth en aplicaciones móviles

Con OAuth 2.0, puede almacenar el secreto en el servidor. Utilice el servidor para adquirir un token de acceso que luego se mueve a la aplicación y puede realizar llamadas desde la aplicación al recurso directamente.

Con OAuth 1.0 (Twitter), se requiere el secreto para realizar llamadas a la API. Las llamadas proxy a través del servidor es la única manera de garantizar que el secreto no se vea comprometido.

Ambos requieren algún mecanismo que su componente de servidor sepa que es su cliente llamándolo. Esto tiende a hacerse en instalación y uso de un mecanismo específico de la plataforma para obtener un id de aplicación de algún tipo en la llamada a su servidor.

(Soy el editor de la especificación OAuth 2.0)

Una solución podría ser codificar el secreto OAuth en el código, pero no como una cadena simple. Ofuscarlo de alguna manera-dividirlo en segmentos, cambiar caracteres por un desplazamiento, rotarlo-hacer cualquiera o todas estas cosas. Un cracker puede analizar tu código de bytes y encontrar cadenas, pero el código de ofuscación puede ser difícil de averiguar.

No es una solución infalible, sino barata.

Dependiendo del valor del exploit, algunos genius crackers pueden ir a mayor longitudes 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 guarde el secreto dentro de la aplicación.

Necesita tener un servidor al que pueda acceder la aplicación a través de 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 enviará la solicitud al servidor que luego agregará el secreto y lo enviará al proveedor de servicios. Su servidor puede decirle a su aplicación si fue exitosa o ni.

Entonces, si necesita obtener cualquier información sensible del servicio (facebook, google, twitter, etc.), la aplicación pregunte a su servidor y su servidor se la dará a la aplicación solo si está correctamente conectada.

No hay realmente ninguna opción excepto almacenarla 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 el cliente contra otros clientes maliciosos (phising)...

OAuth es un protocolo mucho mejor en el navegador que en el escritorio/móvil.

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 aplicaciones instaladas donde utiliza la clave "anónima".

Tal vez pasé por alto algo en la lectura, pero parece que compartir la clave única de su aplicación web con una aplicación instalada es probablemente más seguro que el uso de "anónimo" en el método oficial de aplicaciones instaladas.

Con OAuth 2.0 simplemente puede usar el flujo del lado del cliente para obtener un token de acceso y luego usar este token de acceso para autenticar todas las solicitudes posteriores. Entonces no necesitas ningún secreto.

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

No tengo mucha experiencia con OAuth, pero ¿no requiere cada solicitud no solo el token de acceso del usuario, sino también una clave de consumidor y un secreto de la aplicación? Por lo tanto, incluso si alguien roba un dispositivo móvil e intenta extraer 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 cada Tom, Dick y Harry que tuviera un mashup no tuviera que almacenar sus credenciales de Twitter en el claro. Creo que resuelve ese problema bastante bien a pesar de sus limitaciones. Además, no fue realmente diseñado con el iPhone en mente.

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 a una aplicación de Google App Engine. El hecho de que no pueda administrar de manera confiable el secreto del consumidor en el dispositivo móvil significa que el valor predeterminado es usar el acceso "anónimo".

El paso de autorización del navegador de la implementación de Google App Engine OAuth lo lleva a una página donde contiene texto como: "El sitio está solicitando acceso a su cuenta de Google para los productos enumerados a continuación"

YourApp(yourapp.appspot.com) - no afiliado con Google

Etc

Toma del nombre de dominio/host utilizado en la url de devolución de llamada que proporcione, que puede ser cualquier cosa en Android si usa un esquema personalizado para interceptar la devolución de llamada. Así que si usas acceso 'anónimo' o tu secreto de consumidor está comprometido, entonces cualquiera podría escribir a un consumidor que engaña el usuario en dar 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 gravedad dependiendo de si está utilizando 'anónimo', secreto del consumidor o claves públicas.

Cosas bastante aterradoras para el usuario promedio que no es técnicamente inteligente. No espero tener un alto porcentaje de finalización de registro con ese tipo de cosas en el camino.

Esta entrada de blog aclara cómo los secretos del consumidor realmente no funcionan con aplicaciones instaladas. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api /

También estoy tratando de llegar a una solución para la autenticación móvil OAuth, y el almacenamiento de secretos dentro del paquete de aplicaciones en general.

Y una idea loca me golpeó: La idea más simple es almacenar el secreto dentro del binario, pero ofuscado de alguna manera, o, en otras palabras, se almacena un secreto cifrado. Por lo tanto, eso significa que tienes que almacenar una clave para descifrar su secreto, que parece que nos han llevado al círculo completo. Sin embargo, ¿por qué no utilizar una clave que ya está en el sistema operativo, es decir, es definido por el sistema operativo, no por su aplicación.

Entonces, para aclarar mi idea es que elijas una cadena definida por el sistema operativo, no importa cuál. Luego encripta tu secreto usando esta cadena como clave y guárdala en tu app. Luego, durante el tiempo de ejecución, descifre la variable utilizando la clave, que es solo una constante del sistema operativo. Cualquier hacker que eche un vistazo a su binario verá una cadena cifrada, pero ninguna clave.

¿Funcionará?

Aquí tengo respuesta la forma segura de almacenar su información OAuth en la aplicación móvil

Https://stackoverflow.com/a/17359809/998483

Https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

Facebook no implementa OAuth estrictamente hablando (todavía), pero han implementado una forma para que no incrustes tu secreto en tu aplicación para 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 esto lo arreglará.

Hay una nueva extensión para el Tipo de Concesión de Código de Autorización llamada Proof Key for Code Exchange (PKCE). Con él, no necesitas un secreto de cliente.

PKCE (RFC 7636) es una técnica para asegurar clientes públicos que no utilizan un secreto de cliente.

Es utilizado principalmente por aplicaciones nativas y móviles, pero la técnica puede ser aplicado a cualquier cliente público también. Requiere adicional soporte por el servidor de autorización, por lo que solo se admite en cierto proveedor.

de https://oauth.net/2/pkce/

Para obtener más información, puedes leer el RFC 7636 o esta breve introducción.

Como otros han mencionado, no debería haber ningún problema real con almacenar el secreto localmente en el dispositivo.

Además de eso, siempre puede confiar en el modelo de seguridad basado en UNIX de Android: solo su aplicación puede acceder a lo que escribe en el sistema de archivos. Simplemente escribe la información en el objeto SharedPreferences predeterminado de tu aplicación.

Para obtener el secreto, uno tendría que obtener acceso root al teléfono Android.