¿Cómo autenticar una aplicación móvil sin nombre de usuario y contraseña?

Estoy construyendo un Webapp que utiliza OpenId para autenticar usuarios, como Stackoverlfow. También habrá una aplicación para móviles, por ejemplo, Android o iPhone. Estas aplicaciones tienen que autenticar o iniciar sesión de alguna manera, para acceder a datos y actualizar cosas que pertenecen al usuario. Dado que no hay nombre de usuario y contraseña se podría proporcionar para autenticar el dispositivo móvil, me pregunto cómo lograr esto.

Dos maneras vinieron en mi mente:

  1. Genere una clave en el servidor que debe introducirse en el dispositivo. Esta clave se enviará como auth-key cuando el dispositivo móvil envíe o solicite datos y el usuario pueda estar vinculado de esa manera. Al utilizar esta opción, la clave debe ser transportada de alguna manera al usuario, por lo que no tiene que escribirlo. Tal vez a través de correo electrónico, SMS o escaneando un código de barras.

  2. La aplicación móvil utiliza el navegador o muestra un panel web integrado que abre una página especial del Webapp. En esta página, el usuario debe iniciar sesión y, a continuación, podría permitir que la aplicación móvil lea y escriba datos.

Mi pregunta es: ¿Son posibles ambas formas y ahorrar? ¿Cuál preferirías? ¿Cuáles son los detalles a tener en cuenta? ¿Hay otras maneras de hacer esto? Si lo tengo todo bien, no sería posible usar OpenId en el dispositivo, y vincular el móvil y la aplicación web de esa manera, ¿verdad?

He hecho lo siguiente para lograr esto:

  • Cuando se inicia la aplicación, compruebo si hay un token de autenticación y si sigue siendo válido
  • Si no, utilizo [startActivityForResult] [1] para abrir mi actividad de inicio de sesión
  • LoginActivity utiliza un WebView y abre la página "autenticar la aplicación" (por ejemplo, https://www.sudominio.com/authapp ) de la aplicación web.
  • Si el usuario no está conectado a la aplicación web, tiene que hacerlo ahora. Tras acceder con éxito, se redirige a la página "autenticar la aplicación"
  • La página "autenticar la aplicación" contiene el texto "¿te gustaría que la aplicación móvil accediera a tus datos" y un botón "conceder" y "cancelar".
  • Si el usuario accede a "grant", la aplicación web genera un token de autenticación, lo escribe en la base de datos y redirecciona a una página de respuesta, adjuntando el token de autenticación generado a la URL (por ejemplo, https://www.yourdomain.com/authresponse?auth_token = Dshf84z4388f4h )
  • La aplicación móvil extrae el token de la URL y lo utiliza para la autenticación cuando se habla con el servidor.

    La actividad de WebLogin se ve así: (nota: tienes que anular "shouldOverrideUrlLoading" para permanecer en el mismo WebView. De lo contrario, un nuevo navegador está abierto cuando recibes algún redireccionamiento)

    Public class WebLogin extends Actividad {

    @Override protected void onCreate (Bundle savedInstanceState) {super.onCreate (savedInstanceState);

    WebView webview = new WebView(this); webview.setWebViewClient(new WebViewClient() { @Override public boolean shouldOverrideUrlLoading(WebView view, String url){ view.loadUrl(url); return true; } @Override public void onPageFinished(WebView view, String url) { if(StringUtils.contains(url, "?auth_token=")){ // extract and save token here setResult(RESULT_OK); finish(); } } }); webview.loadUrl("https://www.yourdomain.com/authapp"); webview.getSettings().setJavaScriptEnabled(true); setContentView(webview); 

    }}

Tenga en cuenta que utilizo https para hacer esto guardar. Si utiliza http simple, uno podría leer y robar el token de un usuario.

[1]: http://developer.android.com/reference/android/app/Activity.html#startActivityForResult(android.content.Intent , int)

La especificación OAuth actual (RFC5849) todavía requiere que el usuario introduzca sus credenciales en el sitio web que contiene el recurso protegido. En una aplicación para móviles, esta experiencia de usuario no es la mejor (como señalaste, requiere que la aplicación móvil muestre la página de autenticación con una vista web integrada). OAuth 2.0 soluciona este problema especificando diferentes tipos de concesión de acceso. Esta norma todavía está en borrador. Hasta entonces, lo mejor es probablemente modificar los flujos de OAuth 1.0 para que se adapten a un dispositivo móvil, como ya están haciendo varios sitios grandes (por ejemplo, Twitter con xAuth y Dropbox con su API de desarrollador ).

Estoy haciendo algo similar a la opción (1). Cree un enlace único (incluso incluya el ID de la sesión) y envíelo por SMS. Hay un montón de proveedores de SMS a granel barato con API simples para hacer esto. Cuando el usuario hace clic en la url en el SMS, abrirá el navegador web móvil y los registrará.

Después de eso, si el teléfono acepta cookies, puede configurar uno. De lo contrario, el usuario siempre tendrá que entrar a través de ese enlace único.

  • ¿Cuál es el mejor enfoque para desarrollar una aplicación móvil multiplataforma?
  • Qué ocurre con el código JavaScript después de que la aplicación se compila con Titanium Mobile
  • Titanio api.info nunca muestra nada en la consola
  • ¿Cómo determinar si una aplicación es nativa o html5?
  • Tomar pagos con tarjeta de crédito en la aplicación
  • El impacto del código nativo en el desarrollo de aplicaciones para Android / iPhone
  • Android ListView con estilo como iPhone agrupado UITableView
  • ¿Hay Android concepto de intención en el iPhone SDK
  • Opciones para análisis de tiendas de aplicaciones móviles (Apple, Android, OVI, etc.)?
  • puede LLVM IR (Representación intermedia) ser utilizado para crear multiplataforma (iphone y Android) ARM ejecutables?
  • ¿Podemos instalar Android OS en cualquier Windows Phone y viceversa, y lo mismo con iPhone y viceversa?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.