Arquitectura para Autenticación/Autorización de usuarios móviles y web

Question

Esto parece ser un problema recurrente para mí ya que parece que gravito alrededor de las aplicaciones móviles en los últimos años. Deseo autenticar y autorizar a los usuarios de dispositivos móviles además de a los usuarios de la web. Necesito que esto no tenga problemas para que los usuarios puedan tener una cuenta web sin causar interrupciones en sus datos. Quiero que la solución sea arquitectónica en el tema, no específica de ningún lenguaje/marco.

Requisitos/supuestos

1. Los usuarios móviles deben ser capaces de utilizar la aplicación nativa sin un inicio de sesión, incluso para el aporte de contenidos (marca de favoritos, subir fotos, etc).
2. Los usuarios de dispositivos móviles deben autenticarse de forma segura y única en el servicio web, incluso sin especificar las credenciales de la cuenta.
3. El usuario móvil puede tener varios dispositivos que no se conocen entre sí.
4. El usuario del dispositivo móvil debería poder Registrarse/Iniciar sesión, que debe incluir cualquier contenido en la propiedad de la cuenta. Esta "sincronización" debería ocurrir con cada cuenta que posteriormente inicie sesión.
5. No importa si se creó una cuenta en un dispositivo móvil o web.

Arquitecturas Considerado

1. NO camisa, ningunos zapatos, NO LOGIN = NO CONTRIBUCIÓN. Requiere inicio de sesión para contribuir contenido de cualquier tipo. Esto evita la necesidad de "sincronizar" cuentas de dispositivos con una cuenta maestra. Simplemente requiere un solo nombre de usuario/contraseña + tokens para que los dispositivos inicien sesión. Objetos del servidor: Usuario, Rol
2. Autenticación automática de varios dispositivos. El servidor negocia con el dispositivo y le entrega las credenciales que almacena el dispositivo. Cada dispositivo se autentica automáticamente y se asocia con una cuenta anónima hasta que se registre/inicie sesión. Si se produce el registro, la cuenta anónima se convierte en cuenta conocida. Si se produce el inicio de sesión, el contenido de la cuenta anónima se transfiere a una cuenta conocida y luego se descarta. Los dispositivos que pierden los detalles de autenticación automática obtendrán nuevos detalles de autenticación, y la cuenta anónima anterior se abandonará (y luego se descartará) y no podrá restaurarse, ya que nunca se convirtió en una cuenta conocida. Objetos del servidor: usuario, rol, dispositivo

¿Cuál cree que es una buena solución? ¿Uno de estos, o algo más?

Answer 1

El número 2 es lo suficientemente bueno como base para la decisión. Los usuarios odian el registro;) Así que la capacidad de usar el servicio sin registrarse es una buena idea.

Puede usar GUID/UUID para identificar el dispositivo. Y úselo como inicio de sesión anónimo antes de iniciar sesión.

¿Pero qué hacer si 2 (o más) personas usan 1 dispositivo? O el dispositivo se perderá, se lo robarán? Creo que ninguno de los puntos cubre estos casos.

No tengo idea de qué tipo de servicio web usted arquitecto, así que no puedo aconsejar más.

Answer 2

Me gustaría proponer una idea similar a 2.

Genera un UUID por dispositivo móvil. Servirá para identificar el dispositivo en casos posteriores cuando el usuario genera contenido y el contenido se envía al servidor.

Si, en cualquier momento posterior, el usuario desea crear una cuenta web, puede registrarse en la web o en el dispositivo. Si el usuario ya posee una cuenta web, puede optar por proporcionar las credenciales existentes en su dispositivo móvil una vez (o dispositivos) y el dispositivo está vinculado a su cuenta web en el lado del servidor.

En el lado del servidor, permitiría dos tipos diferentes de entidades que sirven como identidades: usuarios web que están autenticados por credenciales (me viene a la mente OpenID como una adición) y dispositivos que son autentificados por su GUID sin interferencia del usuario. Naturalmente, una entidad de usuario web puede ser propietaria de varias entidades de dispositivo. Una entidad de dispositivo está vinculada a una cuenta cuando el usuario opta por vincular su dispositivo a una cuenta existente. El contenido generalmente se asocia con una identidad.

La vinculación entre el usuario y el dispositivo se mantiene y también se puede utilizar para mostrar el origen del contenido.

No necesitaría crear/soltar/convertir cuentas con credenciales generadas para usuarios móviles. Tampoco necesitaría almacenar las credenciales en el dispositivo móvil.

Todavía hay algunas consideraciones de seguridad que quedan abiertas, dependiendo de la gravedad del contexto de su aplicación. Sin ninguna medida de seguridad, un atacante encontraría que es fácil abusar del UUID.

Answer 3

Creo que esto se está mirando desde la dirección incorrecta. Defina una identidad en el servidor como definida por un valor arbitrario. Probablemente solo una secuencia de DB. Asociar cualquier información demográfica (nombre, correo electrónico ...) e historial de uso con esta identidad.

Por separado, defina una entidad de autenticación en el servidor. Esto podría ser un usuario/contraseña. Podría ser un dispositivo GUID/UUID. Podría ser una identificación federada como OpenID. Una identidad determinada puede tener (y muchas veces lo hará en su caso de uso) múltiples entidades de autenticación asociadas. Muy posiblemente múltiples identidades de autenticación del mismo tipo. (por ejemplo, GUID para mi teléfono inteligente, GUID para mi iPad ...)

Sus front-ends (ya sean basados ​​en web o en aplicaciones) utilizan una API definida para autenticar a un usuario; utilizando cualquiera de los mecanismos que admite el front-end.

En algunos casos (particularmente en la aplicación nativa), la presentación de una ID desconocida desencadena la creación de una nueva identidad. Sin embargo, como alguien señaló, en esta situación debe preguntarle al usuario si quiere conectarse con una identidad existente. Necesitan proporcionar autenticación como esa identidad (una vez) para establecer esa conexión.

Otro punto, cualquiera que sea el servidor que use para especificar de manera única una identidad, debe ser un valor nunca proporcionado a un cliente. Los clientes solo conocen el mecanismo de autenticación y sus datos. Es decir, el GUID/UUID, nombre de usuario/contraseña, ...

Además de las técnicas enumeradas anteriormente, algo así como OAuth es más seguro que un GUID generado localmente. Esos son: fáciles de determinar o b: fácilmente perdidos. Si el valor es altamente predecible (digamos # de teléfono) se puede falsificar fácilmente. Si se genera en tiempo de ejecución e incluye un valor difícil de predecir como el hash de la hora actual cuando se genera por primera vez, entonces debe almacenarse en el dispositivo y se puede perder fácilmente si se limpia el dispositivo. Se pueden generar buenos GUID, pero a menudo son muy específicos del tipo de dispositivo. Cosas como números de serie de dispositivos recuperados de ROM, IMEI, ... Esto es fácilmente factible.Pero, es mucho más específico, depende del dispositivo de lo que probablemente me sienta cómodo.

El mayor obstáculo real que veo en este enfoque es que será incómodo permitir que un usuario existente solo de dispositivo (sin nombre de usuario/contraseña) se siente en el navegador de una PC y se conecte a su cuenta existente.

Answer 4

Una solución es con un sistema biométrico. Si el dispositivo móvil tiene un sensor biométrico, como un lector de huellas dactilares, el usuario inscribirá datos biométricos con el dispositivo (solo debido a problemas de privacidad) en el momento de la compra. Las aplicaciones se pueden escribir de manera que cada transacción segura requiera que el usuario autentique la información biométrica.

Esto no parece estar muy lejos. Motorola Atrix tiene un sensor de huellas digitales ...