2011-11-30 24 views
8

¿Es posible hacer que Oauth sea seguro en iOS?¿Es posible hacer que Oauth sea seguro en iOS?

Estoy investigando OAuth 2.0 como un medio para implementar el inicio de sesión único + autorización para un "conjunto" de aplicaciones de iOS. Para explicar mis inquietudes, simplificaré y usaré Facebook + una aplicación de terceros que use Facebook para la autenticación (digamos Palabras/"Palabras con amigos").

A los efectos de ejemplo, voy a suponer que Facebook se registra para soportar el esquema/protocolo "facebook: //" y que las palabras se registra para apoyar "las palabras: //"

también hago el supuesto de que no es posible asegurar el "secreto del cliente" o el protocolo en una aplicación de iOS porque puede descompilar la aplicación. Cualquier forma que haya surgido para asegurar esto da como resultado security by obscurity.

Otra suposición es que no hay forma de evitar que dos aplicaciones se registren para manejar el mismo protocolo. El comportamiento cuando dos aplicaciones se registran para el mismo protocolo es indeterminado. (Aunque parece que la primera aplicación para iniciar en el dispositivo se registra mientras se ignora el segundo registro de aplicaciones)

Si entiendo el flujo de trabajo entre Facebook (usuario-agente) y Palabras (cliente) en el dispositivo iOS:

  • usuario lanza Palabras
  • usuario decide iniciar sesión a través de credenciales de Facebook
  • Palabras invoca OpenUrl ("facebook: //"), que contiene, entre otras cosas, un identificador para las palabras como una aplicación y un URI de redirección (es decir, "palabras: //")
  • iOS inicia la aplicación de Facebook
  • Credenciales de usuario enteres, cuya aplicación de Facebook valida contra el servidor de autorizaciones de Facebook.
  • usuario se le pide que autorice palabras para acceder a los datos de Facebook (es decir, palabras pueden acceder a mi lista de amigos)
  • Facebook invoca URI de devolución de llamada proporcionada por palabras junto con el token de acceso (es decir, las palabras: // señal_acceso token_here)
  • Palabras usos este símbolo para acceder a mi lista de amigos (datos de recursos es decir protegidas)

Asumiendo lo anterior es correcto, si quiero ser malicioso y el acceso de las personas al azar lista de amigos, que podría crear una aplicación que registra además de manejar el protocolo "words: //" y obténgala en la tienda de aplicaciones. Si alguien tiene mi aplicación y Words instalados, y mi aplicación es la que se registró correctamente (es decir,puso en marcha el dispositivo antes de Palabras), entonces:

  • Palabras lanzamiento, deciden abrir una sesión, lanzamientos de Facebook
  • usuario se autentica/autoriza
  • Facebook intenta volver a dirigir de nuevo a palabras invocando OpenUrl en la URL de redireccionamiento
  • Mi Aplicación (no palabras) se puso en marcha
  • Mi aplicación tiene acceso al código de autenticación, que (con el secreto aprendido decompilando) puede ser intercambiado por un señal_acceso, con derecho a acceder a su lista de amigos

Espero que mi razonamiento sea erróneo anteriormente o tendría que concluir (específicamente) que la autenticación de Facebook iOS para aplicaciones de terceros es insegura.

Más genéricamente, es posible implementar OAuth 2.0 (autorización/flujos de trabajo de concesión implícitos) de forma segura en la aplicación iOS?

+0

¿Se refiere a OAuth en general o específicamente Facebook usando la API de Facebook para iOS? Para OAuth en general, debería poder manejar la autenticación dentro de una vista web en su aplicación, eliminando la necesidad de registrar URL personalizadas. –

+0

OAuth en general, pero utilizando los flujos de trabajo de concesión de autorización/implícita. – jayraynet

Respuesta

1

Google ha llegado con una solución experimental para este problema que ellos llaman OAuth 2.0 for Installed Applications.

El Google OAuth 2.0 punto final es compatible con aplicaciones que están instaladas en un dispositivo ... se supone que estas aplicaciones no pueden guardar secretos.

Esencialmente, el secreto compartido se trata como no secreto.

En el momento de escribir esto, la mayoría de los servidores OAuth 2.0 no parecen ser compatibles con este diseño experimental.

Este diseño presenta el riesgo de que un atacante podría crear un nuevo cliente que se representa a sí mismo como su aplicación al servidor de autorización (el atacante tendría que obtener el identificador de cliente que usted describe en su pregunta, o siguiendo una de las técnicas sugeridas here).

Sin embargo, este riesgo parece mitigarse por el hecho de que es improbable que el propietario del recurso (el usuario) autorice a la aplicación maliciosa a tomar medidas sobre recursos protegidos, ya que sabrá que la aplicación no es De hecho, tu aplicación.

Cuestiones relacionadas