2011-11-03 16 views
17

Mi aplicación está diseñada de la siguiente manera: Tengo un servicio web (ejecutándose en GAE, no muy relevante para esta pregunta) y el los datos que contiene este servicio están disponibles a través de un sitio web y a través de aplicaciones móviles y de escritorio.Cómo autorizar aplicaciones móviles con un tercero por oauth PERO conectar a mi servicio, no el tercero

Actualmente, el usuario se autentica en el sitio web a través de Google ClientLogin y las aplicaciones se autentican/obtienen autorización a través del proveedor de Oauth integrado de GAE. (OAuth se usa aquí principalmente para la autenticación, mi aplicación no usa datos externos a través de OAuth que no sean el ID y la dirección de correo electrónico únicos del usuario).

Lo que me gustaría hacer es ampliar la cantidad de servicios que los usuarios pueden usar para iniciar sesión. Debido al factor de complicación de las aplicaciones, parece que necesito OAuth. Pero realmente no puedo conceptualizar adecuadamente cómo debería funcionar este flujo.

Tomemos Facebook como ejemplo. Cuando una aplicación móvil pasa por el flujo oauth de Facebook y adquiere un token de acceso, esto no es suficiente, porque es mi servicio, no la aplicación, que realmente necesita hablar con Facebook para recuperar información de contacto y una identificación de usuario única. Esto me lleva a pensar que el proceso OAuth debe ocurrir en el contexto de mi servicio, y no en la aplicación móvil. Mi servicio se convierte entonces en el consumidor y Facebook el oauth providor, y el servicio conserva el token de acceso oauth, esto sucede cuando un usuario configura su cuenta por primera vez.

Si este es el enfoque correcto, ¿dónde deja eso la autenticación para las aplicaciones? ¿Qué sucede cuando el usuario ya tiene una cuenta e instala una nueva instancia de una aplicación móvil? También me imagino realizando el proceso oauth, haciendo coincidir credenciales con los datos ya almacenados por mi servicio, y luego emitiendo mi propio "token de acceso" a la aplicación desde el servicio, para autorizar esa instancia de la aplicación. Esto parece intrincado y hackish.

Estoy seguro de que no puedo ser la única persona que de hecho está "pidiendo prestado" el sistema de cuenta de un tercero para una aplicación móvil con un back-end, pero realmente no veo cuál es la forma correcta de haz esto es

¿Qué no estoy viendo y/o estoy conceptualmente equivocado?

+0

* Crickets * Siento que podría haber formulado esta pregunta incorrectamente. Si es así, por favor hágamelo saber. De lo contrario, responderé mi propia pregunta aquí ... con el tiempo. – tempy

Respuesta

10

Algunos colegas y yo una vez hicimos un proyecto bastante similar en la naturaleza, en la universidad. Autenticamos a nuestros usuarios a través de Facebook o Foursquare, usando sus respectivas API de OAuth.

La versión nativa de Android de la aplicación abrió un WebView con la página de inicio del proveedor OAuth, que redirigió a nuestro servicio después de la autenticación. Luego, nuestro servicio solicitó el token de OAuth al proveedor de OAuth (Foursquare tiene algunos pretty simple instructions). Cuando obtuvimos esa ficha, configuramos una sesión usando cookies, a la que pudimos acceder desde la aplicación.

Para validar las sesiones, simplemente comprobamos si el token de acceso seguía siendo válido con el proveedor. También usamos los ID de usuario únicos de los proveedores respectivos para distinguir a los usuarios.

Así que sí, lo que funcionó para nosotros es: hacer que la aplicación autentique & autorice su servicio , no la aplicación en sí.

+0

Entonces, ¿tu aplicación almacenaba estas cookies y las usaba para autenticarse en el servicio, y unirías la cookie al token oauth apropiado en tu servicio? ¿Es eso diferente a solo generar un guid y entregárselo a la aplicación? – tempy

+0

Exactamente, la aplicación estaba usando esas cookies almacenadas (que contienen ID cifrados, etc.) para autenticarse en el servicio, que luego hablaría con los proveedores de OAuth (para verificar si el token todavía era válido). También podría usar algún tipo de GUID, pero debe dificultar el hacerse pasar por esa aplicación, p. tiene algo que solo el servidor sabe para verificar. – Rich

+1

Afortunadamente, la aplicación no trata datos particularmente confidenciales en mi caso. Pero aún así, este enfoque tiene sentido, pero parece un poco demasiado "roll the own" ish. Es una solución, pero me pregunto si este es el enfoque de consenso sobre este tema. – tempy

Cuestiones relacionadas