wake-up-neo.net

Architektur zum Zusammenführen mehrerer Benutzerkonten

Okay, ich habe eine Website, auf der Sie sich registrieren und einloggen können. Sie können sich auch mit Ihrem Facebook-, Twitter- oder Linkedin-Konto anmelden.

Es ist wichtig, dass Benutzer nur ein Konto registriert haben. Irgendwie möchte ich die Konten von Benutzern zusammenführen, wenn sie unterschiedliche Methoden zum Anmelden verwenden. Was ist die beste Lösung, um dies zu lösen?

Beispielsweise meldet sich der Benutzer mit seinem Facebook-Account an. Ich benutze die Daten, um automatisch einen Account für ihn zu erstellen. Soll ich eine E-Mail mit einem Benutzernamen und einem Passwort unserer Website senden? (Wenn dies mit der Politik von Facebook in Ordnung ist). Sollte ich ihnen einen zweiten Bildschirm geben, auf dem sie einen Benutzernamen und ein Passwort eingeben können? Dies ist jedoch nicht die Idee, sich mit Ihrem Facebook-Account anzumelden. Die Teilnahme sollte vereinfacht werden.

Es ist auch möglich, dass sich der Benutzer auf unserer Website registriert hat und sich das nächste Mal mit seinem Twitter-Konto anmeldet. Wie kann ich diese beiden Konten zu einem zusammenführen? Was ist der beste Weg?

Im Grunde ist meine Frage: Ich habe 4 verschiedene Möglichkeiten, wie ein Benutzer Mitglied unserer Website wird. Wie kann ich sicherstellen, dass auf allen vier Wegen nur ein Konto erstellt wird, wenn sich ein Benutzer für mehrere Wege entscheidet? Was ist der beste Ablauf, um sicherzustellen, dass es für den Benutzer selbst kein Ärger wird?


Bearbeiten:

3 Jahre nachdem ich diese Frage gestellt habe, gebe ich die Antwort selbst in einer Reihe von Artikeln: http://www.sitepoint.com/series/using-social-networks-as-a-login-system/

169
P.T.

Ich stehe im Moment vor genau der gleichen Aufgabe. Das Design, das ich ausgearbeitet habe, ist ziemlich einfach, aber es funktioniert gut.

Die Kernidee ist, dass Modelle für eine lokale Site-Identität und die Site-Identitäten von Drittanbietern isoliert bleiben, aber später verknüpft werden. Jeder Benutzer, der sich auf der Site anmeldet, verfügt über eine lokale Identität, die einer beliebigen Anzahl von Site-Identitäten von Drittanbietern zugeordnet ist.

Ein lokaler Identitätsdatensatz enthält nur ein Minimum an Informationen - es kann sich sogar um ein einzelnes Feld handeln - lediglich um einen Primärschlüssel. (Bei meiner Bewerbung sind mir die E-Mail-Adresse, der Name oder das Geburtsdatum des Benutzers egal. Ich möchte nur wissen, dass er sich die ganze Zeit über bei diesem Konto angemeldet hat.)

Die Drittanbieteridentitäten enthalten Informationen, die nur für die Authentifizierung bei einem Drittanbieter relevant sind. Für OAuth bedeutet dies in der Regel eine Benutzerkennung (z. B. eine ID, eine E-Mail oder einen Benutzernamen) und eine Dienstkennung (die angibt, mit welcher Site oder welchem ​​Dienst authentifiziert wurde). In anderen Teilen der Anwendung außerhalb der Datenbank wird diese Dienstkennung mit einer Methode zum Abrufen der relevanten Benutzerkennung von diesem Dienst gepaart, und auf diese Weise wird die Authentifizierung durchgeführt. Für OpenID verwenden wir denselben Ansatz, mit der Ausnahme, dass die Methode zur Authentifizierung allgemeiner ist (da wir fast immer genau dasselbe Protokoll ausführen können - außer, dass wir eine andere Identitäts-URL verwenden und dies unsere Service-ID ist).

Schließlich führe ich Aufzeichnungen darüber, welche Drittanbieteridentitäten mit welcher lokalen Identität verknüpft sind. Um diese Datensätze zu generieren, sieht der Ablauf folgendermaßen aus:

  • Ein Benutzer meldet sich zum ersten Mal mit einer Identität eines Drittanbieters an. Ein lokaler Identitätsdatensatz wird erstellt, dann ein Identitätsdatensatz eines Drittanbieters, und dann werden sie gekoppelt.
  • In einem Control Panel wird dem Benutzer die Möglichkeit geboten, ein Konto zu verknüpfen, indem er sich bei Diensten Dritter anmeldet. (Ziemlich einfach, wie das funktioniert.)
  • In dem Szenario, in dem der Benutzer versehentlich mehrere Konten erstellt, ist die Lösung ziemlich einfach. Während der Benutzer bei einem der Konten angemeldet ist, meldet er sich bei einem anderen Konto an, mit dem er sich zuvor bei der Site angemeldet hat (über die Funktion des Bedienfelds oben). Der Webdienst erkennt diese Kollision (die lokale Identität des angemeldeten Benutzers unterscheidet sich von der lokalen Identität, die mit der soeben angemeldeten Identität eines Drittanbieters verknüpft ist), und der Benutzer wird aufgefordert, ein Konto zusammenzuführen.

Beim Zusammenführen von Konten wird jedes einzelne Feld der lokalen Identität zusammengeführt (was von Anwendung zu Anwendung unterschiedlich ist und einfach sein sollte, wenn Ihre lokalen Identitätsdatensätze nur wenige Felder enthalten). Anschließend müssen die verknüpften Identitäten von Drittanbietern sichergestellt werden sind mit der resultierenden lokalen Identität verknüpft.

118
cheeken

Ich neige dazu, viele Websites zu finden, die aufgrund von E-Mail als überlappendem Verbindungsfaktor zusammengeführt werden.

Ich kann sehen, dass dies eine praktikable Option ist, aber es hängt auch hier von Ihrer Präferenz ab, wie Sie fusionieren. Die E-Mail-Adresse wird in erster Linie verwendet, um wichtige Änderungen auf Ihrer Website zu verifizieren, z. B. das Ändern Ihres Passworts, die Beendigung des Dienstes, der Kontostand ist niedrig usw. Es ist fast so wie beim System der Sozialversicherungsnummern im Internet, verfügt jedoch über die Fähigkeit zur Kommunikation . Kulturell: Ich denke, es ist vernünftig anzunehmen, dass eine E-Mail eine ziemlich eindeutige Identität für OAuth= Authentifizierungsdienste ist. Zugegeben, es ist das, was die Anmeldeformulare für Facebook und Google verlangen.

Mein aktueller Denkprozess.

Die Anmeldeseite bietet 3 Optionen

  • Die Mitgliedschaft Ihrer eigenen Site
  • Mit Facebook einloggen
  • Loggen Sie sich mit Google ein

1) Benutzeranmeldungen zum ersten Mal: ​​Auslösen eines Registrierungsflusses, bei dem ein Konto zum ersten Mal erstellt und gefüllt wird.

 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     | "[email protected]" |  *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     | [email protected] |  myCoolPwd  ]

2) Zu einem anderen Zeitpunkt kehrt der Nutzer zurück, entscheidet sich jedoch dafür, auf das Google-Login zu klicken

      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) Jetzt haben Sie in dem Konto, dem Sie vertrauen, dass die E-Mails in Ihren Datenbankeinträgen dieselben sind, denen Sie in den externen Anmeldungen vertrauen.

Also für nachfolgende Logins

Was ist, wenn Sie zuerst externe Logins haben und sich dann später ein Benutzer mit einem Passwort anmelden kann?

Ich sehe zwei einfache Möglichkeiten, dies zu tun

  • Fordern Sie bei jeder ersten Anmeldung, bei der ein Konto über eine externe Authentifizierung erstellt wird, ein Kennwort an, um die erste Eingabe in Ihre Anwendung abzuschließen

  • Wenn sie sich bereits über Facebook oder Google registriert haben, wollten sie sich irgendwie über das Registrierungsformular Ihrer eigenen Website registrieren. Ermitteln Sie, ob die von ihnen eingegebene E-Mail-Adresse bereits vorhanden ist, fragen Sie sie nach einem Kennwort und senden Sie ihnen nach Abschluss der Registrierung eine E-Mail-Bestätigung.

42
Max Alexander

Ich habe das mit sled.com durchgemacht. Hier gibt es mehrere Probleme hinsichtlich der Erstellung von Konten und der Unterstützung mehrerer Drittanbieter-Konten für die Anmeldung. Einige von ihnen sind:

  • Müssen Sie sowohl ein lokales Kennwort als auch Anmeldungen von Drittanbietern unterstützen?

Für sled.com habe ich mich entschieden, ein lokales Passwort zu löschen, da es einen geringen Mehrwert bietet und zusätzliche Kosten für die Sicherung eines Passworteingabeformulars anfallen. Es gibt viele bekannte Angriffe zum Brechen von Passwörtern. Wenn Sie Passwörter einführen möchten, müssen Sie sicherstellen, dass diese nicht leicht zu knacken sind. Sie müssen sie auch in einem One-Way-Hash oder ähnlichem aufbewahren, um ein Durchsickern zu verhindern.

  • Wie viel Flexibilität möchten Sie bei der Unterstützung mehrerer Drittanbieter-Konten einräumen?

Es hört sich so an, als hätten Sie bereits die drei Anmeldeanbieter ausgewählt: Facebook, Twitter und LinkedIn. Das ist großartig, weil es bedeutet, dass Sie OAuth) verwenden und mit einer Reihe von vertrauenswürdigen Anbietern zusammenarbeiten. Ich bin kein Fan von OpenID. Die verbleibende Frage ist, ob Sie mehrere Drittanbieter unterstützen müssen. Party-Accounts vom selben Provider (zB ein lokaler Account mit zwei verknüpften Twitter-Accounts) Ich gehe davon aus, dass dies nicht der Fall ist, aber wenn Sie dies tun, müssen Sie dies in Ihrem Datenmodell berücksichtigen.

Für Sled unterstützen wir die Anmeldung mit Facebook, Twitter und Yahoo! und in jedem Benutzerkonto einen Schlüssel für jeden speichern: {"_id": "djdjd99dj", "yahoo": "dj39djdj", Twitter: "3723828732", "facebook": "12837287"}. Wir richten eine Reihe von Einschränkungen ein, um sicherzustellen, dass jedes Drittanbieter-Konto nur mit einem einzelnen lokalen Konto verknüpft werden kann.

Wenn Sie mehrere Konten desselben Drittanbieters zulassen möchten, müssen Sie Listen oder andere Strukturen verwenden, um dies und damit alle anderen Einschränkungen zu unterstützen, um die Eindeutigkeit sicherzustellen.

  • Wie verknüpfe ich mehrere Konten?

Wenn sich der Benutzer zum ersten Mal für Ihren Dienst anmeldet, wird er zuerst zum Drittanbieter weitergeleitet und erhält eine überprüfte Drittanbieter-ID. Sie erstellen dann ein lokales Konto für sie und sammeln alle anderen gewünschten Informationen. Wir sammeln ihre E-Mail-Adresse und bitten sie, einen lokalen Benutzernamen auszuwählen (wir versuchen, das Formular mit ihrem vorhandenen Benutzernamen des anderen Anbieters auszufüllen). Eine lokale Kennung (E-Mail, Benutzername) ist für die spätere Wiederherstellung des Kontos sehr wichtig.

Der Server weiß, dass dies eine erstmalige Anmeldung ist, wenn der Browser für ein vorhandenes Konto kein Sitzungscookie (gültig oder abgelaufen) hat und das verwendete Drittanbieter-Konto nicht gefunden wird. Wir versuchen, den Benutzer darüber zu informieren, dass er sich nicht nur anmeldet, sondern ein neues Konto erstellt, sodass er hoffentlich anhält und sich stattdessen mit seinem vorhandenen Konto anmeldet, wenn er bereits über ein Konto verfügt.

Wir verwenden genau den gleichen Ablauf, um zusätzliche Konten zu verknüpfen. Wenn der Benutzer jedoch von einem Drittanbieter zurückkommt, wird anhand des Vorhandenseins eines gültigen Sitzungscookies zwischen dem Versuch, ein neues Konto mit einer Anmeldeaktion zu verknüpfen, unterschieden. Wir erlauben nur ein Konto eines Drittanbieters für jeden Typ. Wenn bereits ein Konto verknüpft ist, blockieren Sie die Aktion. Dies sollte kein Problem sein, da die Schnittstelle zum Verknüpfen eines neuen Kontos deaktiviert ist, falls Sie bereits eine haben (pro Anbieter), aber nur für den Fall.

  • Wie werden Konten zusammengeführt?

Wenn ein Benutzer versucht hat, ein neues Drittanbieter-Konto zu verknüpfen, das bereits mit einem lokalen Konto verknüpft ist, werden Sie einfach aufgefordert, zu bestätigen, dass die beiden Konten zusammengeführt werden sollen (vorausgesetzt, Sie können eine solche Zusammenführung mit Ihrem Datensatz durchführen - häufig einfacher gesagt) als erledigt). Sie können ihnen auch eine spezielle Schaltfläche zur Verfügung stellen, um eine Zusammenführung anzufordern. In der Praxis verbinden sie jedoch lediglich ein anderes Konto.

Dies ist eine ziemlich einfache Zustandsmaschine. Der Benutzer kommt vom Drittanbieter mit einer Drittanbieter-Konto-ID zurück. Ihre Datenbank kann sich in einem von drei Zuständen befinden:

  1. Das Konto ist mit einem lokalen Konto verknüpft und es ist kein Sitzungscookie vorhanden -> Anmelden
  2. Das Konto ist mit einem lokalen Konto verknüpft und ein Sitzungscookie ist vorhanden -> Zusammenführen
  3. Das Konto ist nicht mit einem lokalen Konto verknüpft und es ist kein Sitzungscookie vorhanden -> Anmelden
  4. Das Konto ist nicht mit einem lokalen Konto verknüpft und es ist ein Sitzungscookie vorhanden -> Zusätzliches Konto verknüpfen

    • Wie führe ich eine Kontowiederherstellung bei Drittanbietern durch?

Dies ist immer noch experimentelles Gebiet. Ich habe kein perfektes UX dafür gesehen, da die meisten Dienste neben den Konten von Drittanbietern sowohl ein lokales Kennwort als auch den Anwendungsfall "Passwort vergessen" angeben und nicht alles andere, was schief gehen kann.

Bei Sled haben wir uns für die Option "Benötigen Sie Hilfe beim Anmelden?" Entschieden. Wenn Sie auf klicken, fragen Sie den Benutzer nach seiner E-Mail-Adresse oder seinem Benutzernamen. Wir schauen nach und wenn wir ein passendes Konto finden, senden Sie diesem Benutzer eine E-Mail mit einem Link, über den er sich automatisch beim Service anmelden kann (einmalig). Sobald sie eingegangen sind, werden sie direkt zur Seite mit den Kontenverknüpfungen weitergeleitet. Dort werden sie aufgefordert, einen Blick darauf zu werfen und möglicherweise zusätzliche Konten zu verknüpfen. Außerdem werden ihnen die bereits verknüpften Drittanbieter-Konten angezeigt.

34
Eran Hammer

Beide Ansätze für das automatische Zusammenführen von Konten hinterlassen eine ziemlich große Sicherheitsanfälligkeit, die es jemandem ermöglichen würde, ein Konto zu übernehmen. Beide scheinen davon auszugehen, dass der Benutzer derjenige ist, von dem sie sagen, dass er sie sind, wenn sie einem registrierenden Benutzer die Option zum Zusammenführen anbieten.

Meine Empfehlung zur Minderung der Sicherheitsanfälligkeit lautet, dass der Benutzer sich vor dem Zusammenführen bei einem der bekannten Identitätsanbieter authentifizieren muss, um die Identität des Benutzers zu überprüfen.

Beispiel: Benutzer A registriert sich mit Facebook-Identität. Einige Zeit später kehren sie zu Ihrer Site zurück und versuchen, mit Windows Live ID darauf zuzugreifen und den Registrierungsprozess zu starten. Ihre Website fordert Benutzer A auf mit ... Sie haben sich anscheinend bereits bei Facebook registriert. Bitte melden Sie sich mit Facebook an (Link angeben), damit wir Ihre Windows Live ID mit Ihrem vorhandenen Profil zusammenführen können.

Eine andere Alternative besteht darin, ein gemeinsames Geheimnis (Passwort/persönliche Frage) bei der Erstregistrierung zu speichern, das der Benutzer beim Zusammenführen von Identitäten angeben muss. Dies versetzt Sie jedoch wieder in die Lage, gemeinsame Geheimnisse zu speichern. Dies bedeutet auch, dass Sie mit dem Szenario fertig werden müssen, in dem sich der Benutzer nicht an das gemeinsam genutzte Geheimnis und den damit verbundenen Workflow erinnert.

21
Brad J

Die meisten Beiträge sind ziemlich alt und ich denke, Googles kostenloser Firebase-Authentifizierung Service gab es noch nicht. Nach der Überprüfung mit OAuth übergeben Sie das Token OAuth=) und erhalten eine eindeutige Benutzer-ID, die Sie als Referenz speichern können. Unterstützte Anbieter sind Google, Facebook, Twitter, GitHub und es gibt eine Option für Registrieren Sie benutzerdefinierte und anonyme Anbieter.

2
galki

Großartige Antworten und Ressourcen oben. Mein Beitrag ist hier zusammengefasst ... https://github.com/JavascriptMick/learntree.org/blob/master/design/Schema.md

TLDR: Separate Konto- und Personenschemata. 2 Varianten von Account, Email und OAuth.

Konto -authentifiziert-> Person

0