[Architecture] Архитектура для объединения нескольких учетных записей пользователей вместе


Answers

Я склоняюсь к тому, что многие сайты слияния основаны на электронной почте как перекрывающий фактор объединения.

Я вижу, что это жизнеспособный вариант, но опять же это зависит от вашего предпочтения о том, как слиться. Адрес электронной почты является основным способом, который люди используют для проверки некоторых важных изменений информации на вашем сайте, таких как смена пароля, прекращение обслуживания, низкий баланс счета и т. Д. Это почти как система номеров социального страхования в Интернете, но с возможностью общения , В культурном плане: я думаю, что разумно предположить, что электронное письмо является довольно уникальной идентификацией через службы аутентификации OAuth. Конечно, это то, что для входа в Facebook и Google требуется для входа в систему.

Мой нынешний процесс мышления.

На странице входа есть 3 варианта

  • Членство в вашем собственном сайте
  • Войти с Facebook
  • Войти в Google

1) Вход пользователя в первый раз: запуск потока регистрации, когда учетная запись создается и заполняется в первый раз.

 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) В какой-то другой момент пользователь возвращается, но решает щелкнуть по Google Войти

      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) Теперь вы слились с учетной записью, которой доверяете электронной почте в своих записях базы данных, такие же, как те, которым вы доверяете внешним входам.

Итак, для последующих логинов

Итак, что, если у вас есть внешний вход в систему, а затем вы хотите, чтобы пользователь мог войти с паролем позже?

Я вижу два простых способа сделать это

  • При первом входе в систему, когда учетная запись создается из внешнего auth, попросите их ввести пароль для первой записи в ваше приложение

  • Если они уже зарегистрировались с использованием facebook или Google сначала, то каким-то образом захотели зарегистрироваться, используя регистрационную форму своего собственного сайта. Определите, существует ли уже указанный адрес электронной почты, попросите пароль и отправьте им подтверждение по электронной почте после завершения регистрации.

Question

Хорошо, у меня есть сайт, на котором вы можете зарегистрироваться и войти. Вы также можете войти в свою учетную запись на facebook, twitter или linkedin.

Важно, чтобы пользователи регистрировали только одну учетную запись. Поэтому почему-то я хочу объединить учетные записи пользователей, если они используют разные методы для входа в систему. Какое наилучшее решение для решения этой проблемы?

Например, пользователь регистрируется в своей учетной записи Facebook. Я использую данные для регистрации учетной записи для него автоматически. Должен ли я отправить электронное письмо с именем пользователя и паролем нашего сайта? (Если это соответствует политике Facebook). Должен ли я предоставить им второй экран, где они могут заполнить имя пользователя и пароль? Но это не идея войти в систему с вашей учетной записью Facebook. Он должен упростить вашу процедуру для участия.

Также возможно, что пользователь зарегистрировался на нашем веб-сайте, и в следующий раз он войдет в свою учетную запись Twitter. Как я могу объединить эти 2 счета как один? Каков наилучший способ?

Поэтому в основном мой вопрос: у меня есть 4 разных способа, которыми пользователь становится членом нашего сайта. Как я могу убедиться, что все эти 4 способа создают только одну учетную запись, если пользователь решает использовать несколько способов? Каков наилучший поток, чтобы убедиться, что он не стал хлопотом для самого пользователя?

Редактировать:

Через 3 года после того, как я задал этот вопрос, я сам даю ответ в серии статей: http://www.sitepoint.com/series/using-social-networks-as-a-login-system/




Вы должны разрешить вход с одной учетной записи, а затем при входе в систему дать возможность добавить другую другую учетную запись для слияния с ней.




Оба подхода для автоматического слияния учетных записей оставляют довольно большую уязвимость, которая позволила бы кому-то взять на себя учетную запись. Они оба, похоже, делают предположение, что пользователь - это тот, кого они говорят, когда они предлагают вариант слияния регистрирующему пользователю.

Моя рекомендация по смягчению уязвимости заключается в том, чтобы запросить аутентификацию пользователя с одним из известных поставщиков удостоверений до выполнения слияния для проверки личности пользователя.

Пример: пользовательские регистры с идентификатором Facebook. Спустя некоторое время они возвращаются на ваш сайт и пытаются получить доступ с помощью Windows Live ID и начать процесс регистрации. Ваш сайт будет запрашивать пользователя A с ... Похоже, вы уже зарегистрировались в Facebook. Войдите в систему с Facebook (укажите ссылку), и мы сможем объединить ваш идентификатор Windows Live с вашим существующим профилем.

Другая альтернатива - хранить общий секрет (пароль / личный вопрос) при первоначальной регистрации, которую пользователь должен предоставить при слиянии идентификаторов, однако это возвращает вас к делу хранения общих секретов. Это также означает, что вы должны обрабатывать сценарий, когда пользователь не помнит общий секрет и рабочий процесс, который вместе с ним.