Arquitectura para fusionar múltiples cuentas de usuario juntas

Bien, tengo un sitio web donde puedes registrarte e iniciar sesión. También puede iniciar sesión con su cuenta de facebook, twitter o linkedin.

Es importante que los usuarios solo tengan una cuenta registrada. Entonces, de alguna manera, quiero fusionar las cuentas de los usuarios si usan diferentes métodos para iniciar sesión. ¿Cuál es la mejor solución para resolver esto?

Por ejemplo, el usuario inicia sesión con su cuenta de Facebook. Utilizo los datos para registrar una cuenta para él automáticamente. ¿Debo enviar un correo electrónico con un nombre de usuario y contraseña de nuestro sitio web? (Si esto está de acuerdo con la política de Facebook). ¿Debo darles una segunda pantalla donde puedan completar un nombre de usuario y contraseña? Pero esa no es la idea detrás de iniciar sesión con su cuenta de Facebook. Debería simplificar su procedimiento para participar.

También es posible que el usuario se haya registrado en nuestro sitio web y la próxima vez que inicie sesión con su cuenta de Twitter. ¿Cómo puedo fusionar estas 2 cuentas como una? Cual es la mejor manera?

Básicamente, mi pregunta es: tengo 4 formas diferentes en que un usuario se convierte en miembro de nuestro sitio web. ¿Cómo puedo asegurarme de que estas 4 formas solo creen una cuenta si un usuario decide usar varias formas? ¿Cuál es el mejor flujo para asegurarse de que no se convierta en una molestia para el propio usuario?

Editar:

3 años después de hacer esta pregunta, me estoy dando la respuesta en una serie de artículos: https://www.peternijssen.nl/social-network-authentication-setup/
https://www.peternijssen.nl/social- network-autenticación-google /
https://www.peternijssen.nl/social-network-authentication-merging-accounts/
https://www.peternijssen.nl/social-network-authentication-twitter-facebook/

Me enfrento exactamente a la misma tarea en este momento. El diseño que realicé es bastante simple, pero funciona bien.

La idea central es que los modelos para una identidad de sitio local y las identidades de sitio de terceros se mantienen aisladas, pero luego se vinculan. Por lo tanto, cada usuario que inicia sesión en el sitio tiene una identidad local que se asigna a cualquier número de identidades de sitios de terceros.

Un registro de identidad local contiene un mínimo de información, incluso podría ser un solo campo, solo una clave primaria. (Para mi aplicación, no me importa el correo electrónico, el nombre o la fecha de nacimiento del usuario; solo quiero saber si es la persona que ha estado iniciando sesión en esta cuenta todo el tiempo).

Las identidades de terceros contienen información relevante solo para la autenticación con un tercero. Para OAuth, esto generalmente significa un identificador de usuario (como una identificación, correo electrónico o nombre de usuario) y un identificador de servicio (que indica con qué sitio o servicio se autenticó). En otras partes de la aplicación, fuera de la base de datos, ese identificador de servicio se combina con un método para recuperar el identificador de usuario relevante de ese servicio, y así es como se realiza la autenticación. Para OpenID, empleamos el mismo enfoque, excepto que el método de autenticación es más generalizado (porque casi siempre podemos realizar exactamente el mismo protocolo, excepto que usamos una URL de identidad diferente, y ese es nuestro identificador de servicio).

Finalmente, mantengo un registro de las identidades de terceros que se emparejan con la identidad local. Para generar estos registros, el flujo se ve así:

• Un usuario inicia sesión por primera vez con una identidad de terceros. Se crea un registro de identidad local, luego un registro de identidad de terceros y luego se emparejan.
• En un panel de control, se le ofrece al usuario la oportunidad de vincular una cuenta iniciando sesión en servicios de terceros. (Bastante sencillo cómo funciona esto).
• En el escenario en el que el usuario involuntariamente crea varias cuentas, la solución es bastante simple. Mientras el usuario inicia sesión en una de las cuentas, inicia sesión en otra que utilizó anteriormente para iniciar sesión en el sitio (a través de la función del panel de control anterior). El servicio web detecta esta colisión (que la identidad local del usuario conectado difiere de la identidad local que está vinculada a la identidad de un tercero que acaba de iniciar sesión) y se le solicita al usuario que combine la cuenta.

Fusionar cuentas es una cuestión de fusionar cada campo individual de la identidad local (que variará de una aplicación a otra, y debería ser fácil si solo tiene un par de campos en sus registros de identidad local), y luego garantizar las identidades de terceros vinculadas están vinculados a la identidad local resultante.

Tiendo a encontrar muchos sitios fusionados basados ​​en el correo electrónico como factor de unión superpuesto.

Puedo ver que esta es una opción viable, pero nuevamente depende de su preferencia sobre cómo fusionarse. La dirección de correo electrónico es la forma principal en que las personas usan para verificar algunos cambios importantes de información en su sitio, como cambiar su contraseña, finalización del servicio, saldo de la cuenta, etc. . Culturalmente: creo que es razonable suponer que un correo electrónico es una identidad bastante única en todos los servicios de autenticación de OAuth. De acuerdo, es lo que piden los formularios de inicio de sesión para Facebook y Google.

Mi proceso de pensamiento actual.

La página de inicio de sesión tiene 3 opciones

• La membresía de su propio sitio
• Iniciar sesión con Facebook
• Inicia sesión con google

1) El usuario inicia sesión por primera vez: desencadena un flujo de registro donde se crea y se completa una cuenta por primera vez.

 if the user logins using Facebook (or whatever 3rd party login)
      1) call the Facebook api asking for their information (email, name, etc...) 
      2) create an account membership entry in your database somewhat like this 

         Table = Users
         [ UserId   |       Email             | Password ]
         [    23     | "newuser@coolmail.com" |  *null*  ]

      3) create an external auths entry like so
         *ProviderUserId is the unique id of that user on the provider's site

         Table = ExternalAuths
         [ ExternalAuthId  |  User_UserId   | ProviderName |   ProviderUserId  ]
         [    56           |      23        |   Facebook   |  "max.alexander.9"]

 if the user wants to create an account with your own registration it would just be this           

         Table = Users
         [ UserId   |       Email           |   Password  ]
         [    23     | newuser@coolmail.com |  myCoolPwd  ]

2) En otro momento, el usuario regresa pero decide hacer clic en Google Login

      1) call the Google api asking for their information (email, name, etc...) 

      2) once you get the email, match it up to the userId entry with the existing email 

      3) create an additional External auth entry as such

         Table = ExternalAuths
         [ ExternalAuthId  |  User_UserId   | ProviderName |   ProviderUserId  ]
         [    56           |      23        |   Facebook   |  "max.alexander.9"]
         [    57           |      23        |    Google    |  "1234854368"     ]

3) Ahora que se ha fusionado en la cuenta en la que confía, el correo electrónico en las entradas de su base de datos son los mismos en los que confía desde los inicios de sesión externos.

Entonces para inicios de sesión posteriores

Entonces, ¿qué sucede si primero tiene inicios de sesión externos y luego desea que un usuario pueda iniciar sesión con una contraseña más adelante?

Veo dos formas fáciles de hacer esto.

• En cualquier primer inicio de sesión cuando se crea una cuenta desde una autenticación externa, solicite una contraseña para completar su primera entrada en su aplicación

• Si ya se han registrado usando Facebook o Google primero, de alguna manera querían registrarse usando el formulario de registro de su propio sitio. Detecte si la dirección de correo electrónico que ingresaron ya existe, solicite una contraseña y envíeles un correo electrónico de confirmación una vez que se complete el registro.

He pasado por esto con sled.com. Aquí hay múltiples problemas con respecto a la creación de cuentas y el soporte de múltiples cuentas de terceros para iniciar sesión. Algunos de ellos son:

• ¿Necesita admitir tanto una contraseña local como inicios de sesión de terceros?

Para sled.com, he decidido eliminar la contraseña local debido al pequeño valor que agrega y el costo adicional de asegurar un formulario de ingreso de contraseña. Hay muchos ataques conocidos por romper contraseñas y si va a introducir contraseñas debe asegurarse de que no sean fáciles de romper. También debe almacenarlos en un hash unidireccional o similar para evitar que se filtren.

• ¿Cuánta flexibilidad desea permitir para admitir múltiples cuentas de terceros?

Parece que ya eligió los tres proveedores de inicio de sesión: Facebook, Twitter y LinkedIn. Eso es genial porque significa que está utilizando OAuth y está trabajando con un conjunto bien definido de proveedores confiables. No soy fanático de OpenID. La pregunta restante es si necesita admitir varias cuentas de terceros del mismo proveedor (por ejemplo, una cuenta local con dos cuentas de Twitter vinculadas). Supongo que no, pero si lo hace, deberá acomodar eso en su modelo de datos.

Para Sled, admitimos el inicio de sesión con Facebook, Twitter y Yahoo! y dentro de cada cuenta de usuario, guarde una clave para cada una: {"_id": "djdjd99dj", "yahoo": "dj39djdj", twitter: "3723828732", "facebook": "12837287"}. Configuramos un montón de restricciones para garantizar que cada cuenta de terceros solo se pueda vincular a una sola cuenta local.

Si va a permitir varias cuentas del mismo proveedor externo, necesitará usar listas u otras estructuras para respaldar eso, y con eso, todas las otras restricciones para garantizar la unicidad.

• ¿Cómo vincular varias cuentas?

La primera vez que el usuario se registra en su servicio, primero va al proveedor externo y regresa con una identificación de tercero verificada. Luego crea una cuenta local para ellos y recopila cualquier otra información que desee. Recopilamos su dirección de correo electrónico y también les pedimos que elijan un nombre de usuario local (intentamos rellenar previamente el formulario con su nombre de usuario existente del otro proveedor). Tener alguna forma de identificador local (correo electrónico, nombre de usuario) es muy importante para la recuperación de la cuenta más adelante.

El servidor sabe que este es un inicio de sesión por primera vez si el navegador no tiene una cookie de sesión (válida o caducada) para una cuenta existente, y que no se encuentra la cuenta de terceros utilizada. Intentamos informar al usuario que no solo están iniciando sesión, sino que están creando una nueva cuenta para que si ya tienen una cuenta, esperemos que pausen e inicien sesión con su cuenta existente.

Usamos exactamente el mismo flujo para vincular cuentas adicionales, pero cuando el usuario regresa de un tercero, la presencia de una cookie de sesión válida se utiliza para diferenciar entre un intento de vincular una nueva cuenta a una acción de inicio de sesión. Solo permitimos una cuenta de terceros de cada tipo y, si ya hay una vinculada, bloquea la acción. No debería ser un problema porque la interfaz para vincular una nueva cuenta está desactivada si ya tiene una (por proveedor), pero por las dudas.

• ¿Cómo fusionar cuentas?

Si un usuario intentó vincular una nueva cuenta de terceros que ya está vinculada a una cuenta local, simplemente solicite que confirme que desea fusionar las dos cuentas (suponiendo que pueda manejar dicha fusión con su conjunto de datos, a menudo es más fácil decirlo). que hecho). También puede proporcionarles un botón especial para solicitar una fusión, pero en la práctica, todo lo que están haciendo es vincular otra cuenta.

Esta es una máquina de estado bastante simple. El usuario regresa del tercero con una identificación de cuenta de terceros. Su base de datos puede estar en uno de tres estados:

1. La cuenta está vinculada a una cuenta local y no hay ninguna cookie de sesión presente -> Iniciar sesión
2. La cuenta está vinculada a una cuenta local y hay una cookie de sesión presente -> Fusionar
3. La cuenta no está vinculada a una cuenta local y no hay una cookie de sesión presente -> Registrarse

4. La cuenta no está vinculada a una cuenta local y hay una cookie de sesión -> Vinculación de cuenta adicional

   • ¿Cómo realizar la recuperación de la cuenta con proveedores externos?

Esto sigue siendo territorio experimental. No he visto una experiencia de usuario perfecta para esto, ya que la mayoría de los servicios proporcionan una contraseña local junto a las cuentas de terceros y, por lo tanto, se centran en el caso de uso "Olvidé mi contraseña", no todo lo demás que puede salir mal.

Con Sled, hemos optado por utilizar "¿Necesita ayuda para iniciar sesión?" y cuando hace clic, solicite al usuario su correo electrónico o nombre de usuario. Lo buscamos y, si encontramos una cuenta coincidente, enviamos un correo electrónico a ese usuario con un enlace que puede iniciar sesión automáticamente en el servicio (válido por una vez). Una vez dentro, los llevamos directamente a la página de vinculación de cuentas, les decimos que deberían echar un vistazo y potencialmente vincular cuentas adicionales, y les mostramos las cuentas de terceros que ya han vinculado.

Ambos enfoques para las cuentas de fusión automática dejan una vulnerabilidad bastante grande que permitiría a alguien hacerse cargo de una cuenta. Ambos parecen suponer que el usuario es quien dice ser cuando ofrece la opción de fusión a un usuario registrado.

Mi recomendación para mitigar la vulnerabilidad es solicitar que el usuario se autentique con uno de los proveedores de identidad conocidos antes de realizar la fusión para verificar la identidad del usuario.

Ejemplo: el usuario A se registra con identidad de Facebook. Algún tiempo después, vuelven a su sitio e intentan acceder con Windows Live ID e inician el proceso de registro. Su sitio le indicará al usuario A ... Parece que ya se ha registrado en Facebook anteriormente. Inicie sesión con Facebook (proporcione un enlace) y podemos combinar su Windows Live ID con su perfil existente.

Otra alternativa es almacenar un secreto compartido (contraseña / pregunta personal) en el registro inicial que el usuario debe proporcionar al fusionar identidades, sin embargo, esto lo lleva nuevamente al negocio de almacenar secretos compartidos. También significa que debe manejar el escenario en el que el usuario no recuerda el secreto compartido y el flujo de trabajo que lo acompaña.

La mayoría de las publicaciones son bastante antiguas y supongo que el servicio gratuito de autenticación Firebase de Google aún no existía. Después de verificar con OAuth, le pasa el token de OAuth y obtiene una identificación de usuario única que puede almacenar como referencia. Los proveedores admitidos son Google, Facebook, Twitter, GitHub y hay una opción para registrar proveedores personalizados y anónimos.

Grandes respuestas y recursos arriba. Mi contribución se resume aquí ... https://github.com/JavascriptMick/learntree.org/blob/master/design/Schema.md

TLDR: esquemas de cuenta y persona separados. 2 variantes de cuenta, correo electrónico y OAuth.

Cuenta-autentica-> Persona

Debe permitir iniciar sesión desde una cuenta, luego, cuando inicie sesión, dé la opción de agregar otra cuenta diferente para fusionarse con ella.