181

さて、私はあなたがあなた自身を登録してログインすることができるウェブサイトを手に入れました。Facebook、Twitter、LinkedInのアカウントでログインすることもできます。

ユーザーが登録しているアカウントは1つだけであることが重要です。だからどういうわけか、ユーザーが異なる方法でログインする場合は、ユーザーのアカウントをマージしたいと思います。これを解決するための最良の解決策は何ですか？

たとえば、ユーザーは自分のFacebookアカウントでログインします。私はそのデータを使用して、彼のアカウントを自動的に登録します。私たちのウェブサイトのユーザー名とパスワードを記載した電子メールを送信する必要がありますか？（これがFacebookのポリシーで問題ない場合）。ユーザー名とパスワードを入力できる2番目の画面を表示する必要がありますか？しかし、それはあなたのFacebookアカウントでログインすることの背後にある考えではありません。参加するための手続きが簡単になるはずです。

また、ユーザーが当社のWebサイトに自分自身を登録し、次にTwitterアカウントでログインした可能性もあります。これらの2つのアカウントを1つにマージするにはどうすればよいですか？最善の方法は何ですか？

つまり、基本的に私の質問は、ユーザーが当社のWebサイトのメンバーになる4つの異なる方法があります。ユーザーが複数の方法を使用することを決定した場合、これら4つの方法すべてで1つのアカウントのみを作成するようにするにはどうすればよいですか？それがユーザー自身にとって面倒にならないようにするための最良の流れは何ですか？

編集：

この質問をしてから3年後、私は一連の記事で自分自身に答えを出します：https: //www.peternijssen.nl/social-network-authentication-setup/
https://www.peternijssen.nl/social- network-authentication-google /
https://www.peternijssen.nl/social-network-authentication-merging-accounts/
https://www.peternijssen.nl/social-network-authentication-twitter-facebook/

4

7 に答える 7

124

私は現在、まったく同じ課題に直面しています。私が作成したデザインはかなりシンプルですが、うまく機能します。

中心的な考え方は、ローカルサイトIDとサードパーティサイトIDのモデルは分離されたままですが、後でリンクされるというものです。したがって、サイトにログインするすべてのユーザーは、任意の数のサードパーティサイトIDにマップされるローカルIDを持っています。

ローカルIDレコードには、最小限の情報が含まれています（単一のフィールドの場合もあります）。主キーのみです。（私のアプリケーションでは、ユーザーの電子メール、名前、または誕生日は気にしません。ユーザーがこのアカウントにずっとログインしている人であることを知りたいだけです。）

サードパーティのIDには、サードパーティによる認証にのみ関連する情報が含まれています。OAuthの場合、これは通常、ユーザー識別子（ID、電子メール、ユーザー名など）とサービス識別子（認証されたサイトまたはサービスを示す）を意味します。アプリケーションの他の部分では、データベースの外部で、そのサービスIDは、そのサービスから関連するユーザーIDを取得するためのメソッドとペアになり、それが認証の実行方法です。OpenIDの場合、認証方法がより一般化されていることを除いて、同じアプローチを採用しています（ほとんどの場合、まったく同じプロトコルを実行できるためです。ただし、異なるID URLを使用し、それがサービスIDです）。

最後に、どのサードパーティIDがどのローカルIDとペアになっているのかを記録します。これらのレコードを生成するためのフローは次のようになります。

  • ユーザーは、サードパーティのIDを使用して初めてログインします。ローカルIDレコードが作成され、次にサードパーティIDレコードが作成され、次にそれらがペアになります。
  • コントロールパネルでは、ユーザーはサードパーティのサービスにログインしてアカウントをリンクする機会が提供されます。（これがどのように機能するかは非常に簡単です。）
  • ユーザーが無意識のうちに複数のアカウントを作成するシナリオでは、解決策は非常に簡単です。ユーザーがアカウントの1つにログインしている間、ユーザーは以前にサイトにログインするために使用した別のアカウントにログインします（上記のコントロールパネル機能を使用）。Webサービスはこの衝突を検出し（ログインしたユーザーのローカルIDが、ログインしたばかりのサードパーティIDにリンクされているローカルIDと異なること）、ユーザーはアカウントのマージを求められます。

アカウントのマージは、ローカルIDの個々のフィールドをマージし（アプリケーションごとに異なり、ローカルIDレコードにフィールドが2つしかない場合は簡単です）、リンクされたサードパーティIDを確認することです。結果として得られるローカルIDにリンクされます。

于 2011-08-02T01:43:16.033 に答える
49

重複する結合要素として、電子メールに基づいてマージするサイトをたくさん見つける傾向があります。

これは実行可能なオプションであることがわかりますが、これもマージ方法の好みによって異なります。メールアドレスは、パスワードの変更、サービスの終了、アカウントの残高が少ないなど、サイトの重要な情報の変更を確認するために使用される主な方法です。これは、ウェブの社会保障番号システムとほぼ同じですが、通信機能を備えています。 。文化的：電子メールはOAuth認証サービス全体でかなり一意のIDであると想定するのが妥当だと思います。確かに、それはFacebookとGoogleのログインフォームが求めるものです。

私の現在の思考プロセス。

ログインページには3つのオプションがあります

  • あなた自身のサイトのメンバーシップ
  • Facebookでログイン
  • グーグルでログイン

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）これで、データベースエントリの電子メールが外部ログインから信頼するものと同じであると信頼するアカウントにマージされました。

したがって、その後のログインでは

では、最初に外部ログインを使用していて、後でユーザーがパスワードを使用してログインできるようにするにはどうすればよいでしょうか。

これを行う簡単な方法が2つあります

  • アカウントが外部認証から作成されたときの最初のログイン時に、アプリケーションへの最初の入力を完了するためにパスワードを要求します

  • 彼らがすでに最初にフェイスブックまたはグーグルを使用して登録している場合、どういうわけかあなた自身のサイトの登録フォームを使用して登録したかった。入力したメールアドレスが既に存在するかどうかを検出し、パスワードを要求し、登録が完了したら確認メールを送信します。

于 2013-01-26T09:23:18.627 に答える
35

私はsled.comでこれを経験しました。アカウントの作成とログイン用の複数のサードパーティアカウントのサポートに関して、ここには複数の問題があります。それらのいくつかは次のとおりです。

  • ローカルパスワードとサードパーティのログインの両方をサポートする必要がありますか？

sled.comの場合、追加する値が小さく、パスワード入力フォームを保護するための追加コストがかかるため、ローカルパスワードを削除することにしました。パスワードを破る攻撃は数多く知られています。パスワードを導入する場合は、簡単に破れないようにする必要があります。また、漏れを防ぐために、一方向ハッシュなどに保管する必要があります。

  • 複数のサードパーティアカウントをサポートする際に、どの程度の柔軟性を許可しますか？

Facebook、Twitter、LinkedInの3つのログインプロバイダーをすでに選択しているようです。これは、OAuthを使用し、明確に定義された一連の信頼できるプロバイダーと連携していることを意味するため、すばらしいことです。私はOpenIDのファンではありません。残りの質問は、同じプロバイダーからの複数のサードパーティアカウントをサポートする必要があるかどうかです（たとえば、2つのTwitterアカウントがリンクされた1つのローカルアカウント）。いいえと思いますが、そうする場合は、データモデルに対応する必要があります。

Sledの場合、Facebook、Twitter、Yahoo！でのログインをサポートしています。各ユーザーアカウント内に、それぞれのキーを保存します：{"_id"： "djdjd99dj"、 "yahoo"： "dj39djdj"、twitter： "3723828732"、 "facebook"："12837287"}。各サードパーティアカウントが単一のローカルアカウントにのみリンクできるように、一連の制約を設定します。

同じサードパーティプロバイダーからの複数のアカウントを許可する場合は、リストまたは他の構造を使用してそれをサポートする必要があります。また、他のすべての制限を使用して一意性を確保する必要があります。

  • 複数のアカウントをリンクする方法は？

ユーザーが初めてサービスにサインアップするとき、ユーザーは最初にサードパーティプロバイダーにアクセスし、検証済みのサードパーティIDを持って戻ってきます。次に、それらのローカルアカウントを作成し、必要なその他の情報を収集します。私たちは彼らの電子メールアドレスを収集し、ローカルユーザー名を選択するように依頼します（他のプロバイダーからの既存のユーザー名をフォームに事前入力しようとします）。何らかの形式のローカル識別子（電子メール、ユーザー名）を持つことは、後でアカウントを回復するために非常に重要です。

サーバーは、ブラウザーに既存のアカウントのセッションCookie（有効または期限切れ）がなく、使用されているサードパーティのアカウントが見つからない場合、これが初めてのログインであることを認識します。ユーザーがログインしているだけでなく、新しいアカウントを作成していることをユーザーに通知します。これにより、ユーザーが既にアカウントを持っている場合は、代わりに既存のアカウントで一時停止してログインできるようになります。

追加のアカウントをリンクするためにまったく同じフローを使用しますが、ユーザーがサードパーティから戻ってきたときに、有効なセッションCookieの存在を使用して、新しいアカウントをログインアクションにリンクする試みを区別します。各タイプのサードパーティアカウントは1つだけ許可されており、すでに1つリンクされている場合は、アクションをブロックします。新しいアカウントをリンクするためのインターフェースが（プロバイダーごとに）すでにある場合は無効になっているため、問題はありませんが、念のためです。

  • アカウントをマージする方法は？

ユーザーがすでにローカルアカウントにリンクされている新しいサードパーティアカウントをリンクしようとした場合、2つのアカウントをマージすることを確認するようにユーザーに求めるだけです（データセットでそのようなマージを処理できると仮定すると、多くの場合、簡単に言うことができます）行われるよりも）。マージをリクエストするための特別なボタンを提供することもできますが、実際には、別のアカウントをリンクするだけです。

これは非常に単純なステートマシンです。ユーザーは、サードパーティのアカウントIDを使用してサードパーティから戻ってきます。データベースは、次の3つの状態のいずれかになります。

  1. アカウントはローカルアカウントにリンクされており、セッションCookieは存在しません->ログイン
  2. アカウントはローカルアカウントにリンクされており、セッションCookieが存在します->マージ
  3. アカウントはローカルアカウントにリンクされておらず、セッションCookieは存在しません->サインアップ

  4. アカウントはローカルアカウントにリンクされておらず、セッションCookieが存在します->追加アカウントのリンク

    • サードパーティプロバイダーでアカウントリカバリを実行するにはどうすればよいですか？

これはまだ実験的な領域です。ほとんどのサービスはサードパーティアカウントの隣にローカルパスワードを提供するため、「パスワードを忘れた」ユースケースに焦点を当てており、他のすべてがうまくいかない可能性があるため、これに最適なUXは見ていません。

Sledでは、「サインインのサポートが必要ですか？」を使用することを選択しました。クリックしたら、ユーザーにメールアドレスまたはユーザー名を尋ねます。調べて、一致するアカウントが見つかった場合は、そのユーザーに、サービスに自動的にログインできるリンクをメールで送信します（1回限り有効）。入ったら、アカウントのリンクページに直接移動し、確認して追加のアカウントをリンクする可能性があることを伝え、すでにリンクしているサードパーティのアカウントを表示します。

于 2011-08-02T06:51:57.297 に答える
23

アカウントを自動マージするための両方のアプローチは、誰かがアカウントを引き継ぐことを可能にするかなり大きな脆弱性を残します。どちらも、登録ユーザーにマージオプションを提供するときに、ユーザーが自分の言うとおりのユーザーであると想定しているようです。

脆弱性を軽減するための私の推奨事項は、ユーザーのIDを確認するためにマージを実行する前に、既知のIDプロバイダーの1つでユーザーに認証を要求することです。

例：ユーザーAはFacebookIDに登録します。しばらくして、彼らはあなたのサイトに戻り、Windows Live IDでアクセスして、登録プロセスを開始しようとします。あなたのサイトはユーザーAに次のように促します...あなたは以前にFacebookに登録したようです。Facebookでログインしてください（リンクを提供してください）。WindowsLiveIDを既存のプロファイルとマージできます。

もう1つの方法は、ユーザーがIDをマージするときに提供する必要がある初期登録に共有シークレット（パスワード/個人的な質問）を保存することですが、これにより、共有シークレットを保存するビジネスに戻ることができます。また、ユーザーが共有シークレットとそれに伴うワークフローを覚えていないシナリオを処理する必要があることも意味します。

于 2012-11-25T12:53:16.210 に答える
1

ほとんどの投稿はかなり古く、Googleの無料のFirebase認証サービスはまだ提供されていなかったと思います。OAuthで確認した後、OAuthトークンを渡し、参照用に保存できる一意のユーザーIDを取得します。サポートされているプロバイダーはGoogle、Facebook、Twitter、GitHubであり、カスタムプロバイダーと匿名プロバイダーを登録するオプションがあります。

于 2016-08-16T07:20:18.023 に答える
0

上記の優れた回答とリソース。私の貢献はここに要約されています... https：//github.com/JavascriptMick/learntree.org/blob/master/design/Schema.md

TLDR：個別のアカウントスキーマと個人スキーマ。アカウント、メール、OAuthの2つのバリエーション。

アカウント-認証->人

于 2018-06-14T22:26:40.610 に答える
-4

1つのアカウントからのログインを許可する必要があります。次に、ログイン時に、別のアカウントを追加してそのアカウントとマージするオプションを指定します。

于 2011-07-12T15:04:33.277 に答える