新しいWebサイトで「Twitter / Facebookでサインイン」を使用することの長所と短所は何ですか？
私と友人は小さなフォーラムサイトを立ち上げようとしています。ユーザーのログインに「Facebook/Twitterでサインイン」APIを使用することを検討しています。これは、もしかすると（例： Lanyrd ）だけです。これまでこれらのどちらも使用したことがなく、ユーザーのログインでサイトを実行したこともありません。まったく。
これらのAPIの長所と短所は何ですか？具体的には：
開発者がそれらを使用することでどのようなメリットがありますか？どのような欠点がありますか？
エンドユーザーは実際にそれらを好き/嫌いですか？
これらのAPIで特に技術的/ロジスティック上の問題を経験しましたか？
ここに私がこれまでに得た長所と短所があります：
長所
- ユーザーにとってより便利（2回のクリックで「登録」、1回でサインイン）
- おそらく私たち自身のログインシステムを維持する必要はありません
短所
- ログインプロセスを制御できない
- 自分のアカウントへの何らかのアクセスを心配しているFacebook/Twitterユーザーを除外する
- Facebook/Twitterアカウントが侵害された場合、当社サイトのユーザーのアカウントも侵害されます。
- また、独自の代替ログインシステムを維持していない場合：
- ログインシステムのFacebook/Twitterへの依存
- Facebook/Twitter以外のユーザーをサイトから除外する
私が言う詐欺は、ユーザーがFacebook/Twitterの資格情報を使用してサイトにログオンし、サイトがそれらのそれぞれのアカウントのすべての情報に完全にアクセスできると思っているという妄想かもしれません。
しないでください。
多くの人々、特に米国に拠点を置いていない人々は、Facebookアカウントを持たず、Facebookとユーザーのプライバシーの無知に関連して言われたことをすべて思い出すことはできません。
多くの人が信じていることに反して、それらのソーシャルノイズやジャンクサイトなしで幸せに暮らしていて、それらについて気にしない人はたくさんいます。
彼らがフェイスブックと呼ばれる大規模なヒステリーに負けていないからといって、なぜ彼らを顔に唾を吐いて拒否しますか？
考慮すべきその他のポイント：
外部システムに依存させることにより、単一障害点を導入します。彼らがOpenIDをシャットダウンしたり、その代金を支払わせたりすることに決めた場合、あなたは大いにねじ込まれています。
彼らはあなたのユーザーとそれをどうするかを知っているユーザーに関するデータを収集します。少なくとも、彼らはそれをマーケティング目的で使用し、最終的にはそれでお金を稼ぎ、パイの一部をあなたに与えません。
それらをOpenIDプロバイダーとして採用することにより、それらの準独占をさらにサポートし、彼らがさらに成長するのを助けます。地域社会の奉仕を行い、その疫病に貢献しないでください。
もう1つの欠点：Facebook以外のユーザーやTwitter以外のユーザー（または、ログイン情報を他のサイトに安全に共有することに不安を感じているユーザー）を除外します。または、外部アカウントを作成させることで、ユーザーに不便をかけます。私は個人的に、誰かが私のFacebook/Twitterのログイン情報を取得すると、同じ情報を使用する他のどのサイトにもアクセスできるという単一障害点の考えは好きではありません。しかし、たぶん私は偏執的だ。
オプションとして使用されていることがわかりますが、FBが必要な場合、潜在的な訪問者のlotが失われますまたはTwitterログイン。たとえ訪問者がFBアカウントを持っているとしても、多くの人はプライバシーの目的でそれらを使用したくありません。私は確かにランダムなサイトに個人を特定する情報を提供したくありません。
また、設定などのサイトに関連するユーザー情報を追跡する必要がある場合があるため、おそらく何らかの形のユーザー追跡システムが依然として必要です。
頻繁にアクセスするサイト には独自のローカルログインシステム/ユーザーアカウントがありますが、ユーザーは必要に応じて自分のアカウントをFacebookアカウントにリンクすることができます。そのため、そうした人々にとっては、必要に応じて簡単にログインできるという利点があり、Facebookのログインを使用したくない場合は、誰も強制的に使用する必要はありません。それはかなりうまくいくと思います。
ログインにOpenID、Facebook、Twitterを使って遊んだ。かつて私はそれをテストしていただけで、何らかの理由でFacebookを使用してログインできませんでした。 Facebook開発者ページを見て、APIサーバーがダウンしていることに気付きました。 Facebookがダウンタイムを抱えているため、ユーザーがログインできない場合、これは大きな欠点です。 Twitterでも、OpenIDと同じ問題が発生する可能性があります。
私はFacebookアカウントを持っていますが、それを使用してログインすることを希望するサイトに直面した場合、私はしません。別の方法がある場合は、それを使用します。そうでなければ、私はとにかくそのサイトに何があるかを本当に見たくありません。私はサイトに行って他のFacebookの友達がそのサイトで何をしたかを見るのが嫌いです。それは不気味でプライバシーを侵害します（特にFacebook経由でログインしたり、サイトに私のFacebookアカウントを伝えなかった場合）。
それは本当にあなたのターゲット市場が何であるかに依存します。たとえば、一部のターゲット市場では、「非ユーザーを除外する」という懸念はごくわずかです（ほとんどすべてのユーザーがそれらを持っているため、喜んで共有します）。他には、それは大きな問題です。
答えはここにあります：プログラマーはセキュリティに非常に注意を払い、アクセスを許可したくないので、すべて "NO！"です。回答:-p非技術者はこれについてあまり注意を払っていません。
しかし、明らかな答えは、可能であればfb/Twitterと独自のシステムの両方を実行することです。その後、みんなが幸せです。
純粋にその方法でそれを行うことの1つの欠点-複雑な外部依存関係なしにローカルでどのようにテストするのですか？ランダムなテストアカウントをどのように設定しますか？デモ口座？人間以外のユーザーアカウント？ほとんどのユーザーが資格情報を外部に保存することを希望している場合でも、通常、これらの順列をカバーするローカル認証スキームが必要です。
最も重要なことは、インターネットに接続していない場合、アプリをハッキングすることも、実質的な作業を行うこともできません。また、認証または承認にバグがある場合、facebook/Twitter/other oauth問題がないことを確認するために単純でローカルなものを実行できない場合、問題がないことをどのように確認できますか？コードは正しいですか？
外部ログインシステムを使用すると非常にうまく機能すると思います。stackoverflowとstackexchangeでopenIDをどのように使用したかを見てください。利点は素晴らしいです。すべてのログインシステムをコーディングする必要はありません。これは、単純に無視できる最初のコードベースからの大きなチャンクであり、間違ってしまう可能性がないので、 elseは、どのような種類のパスワードで十分か、どのようにリセットするかなどを心配させることができます。また、（ブログアカウントから、またはstackoverflowにアクセスするために設定したアカウントから）すでにどこかにopenidがある場合、別のユーザー名/パスワードの組み合わせを覚えておく必要はありません。
短所は、多くのユーザーが少し混乱していることであり、まだ使用していない外部サイトにopenidを作成したくない場合があります。
Facebookのログインを使用すると、これらすべての利点に加えて、許可されている場合はFacebookのアカウントとやり取りできるようになります。
欠点は、facebookだけに依存している場合は、それらに縛られていることです。facebookがAPIを変更したり、サイトを禁止したりした場合、または私のようなユーザーがmayにログインすることを拒否した場合=データFacebookを共有します（他の会社にそのデータを漏らさないようにする場合、それほど慎重ではないことが知られています）。 IIRCであってもhaving Facebookの「いいね」または「ログイン」リンクがページにあると、ダブルクリックして、ログインしたユーザーがサイトを閲覧したFacebookを追跡できるようになります。
だから、私は言うでしょう：
- 理想的には、複数の外部サイト（openIDサイト、facebook、googleなど）でのログインを許可します。
- facebookのログインフォームがある場合は、最初のページに正しく配置せず、ユーザーが[Facebookでログイン]をクリックしたときにのみ表示します（オプションがあることに不満を言うことはありません） =そうする:)）。
- 最初に、アカウントとパスワード、またはopenIDか何かをセットアップするのに最も早いものを決定します。
- 外部ログインしている場合は、アカウントとパスワードも追加する価値があるかどうかを判断します。 （しかし、少なくともいくつかの外部ログインがあることを確認してください）
どうやら、私は別のキャンプにいるようだ。私にとって、Facebookのコンセプトは時の試練に耐えられるものです。おそらくそれは将来Facebookではなくなるだろう。しかし、プライバシーの陰謀論者の懸念（あなたはあなたのプライバシーを制御することができます）を超えて、私の意見はこの種のサービスは「実用性」になるでしょう。あなたが誰かを呼び出すためにあなたの電話を拾うということで、あなたはメールボックスを使い尽くしてメールを手に入れます...
私たちはすでに メールトラフィックが大幅に減少したことを経験しています 代わりに、人々がお互いに「Facebook」になりました。それは時間の問題ですが、電子メールの使用は減少し続けます。
また、システムにログインしたい人のタイプは、Facebookアカウントを持っているタイプの人である可能性が非常に高いことに注意してください。通常は（私の経験から）そうでないものは、とにかくあなたのサイト（または実際にはどのサイト）にも「参加」することはありません。
事実は、それがFacebookであるかどうかに関係なく、誰もが承認した人々と即座に通信できるシステムは、インターネットの「シングルサインオン」システムの最良の候補になるでしょう。 「2クリック登録とno-click/1-clickログイン」を小さなプロとして単純に無視することはできません。
プライバシーを心配している人のために、あなたがあなたのFacebookプロフィールに何を出しているのですか？なぜあなたはそれをそこに出しているのですか？
私の投票（価値があるもの）は賛成です！独り占めして、メンバーシップシステムをFacebookのみのシステムに完全に置き換えてください。 私は持っています、そして私のユーザーは今のところそれが好きです 。
私は少なくとも、ソーシャルメディアの見出し、特に選択的な情報共有を自由に無視するFacebookには警戒しています。この不信には、私が遭遇した一見大多数のアプリがすべての情報を要求し、その後、私が知っている全員の情報がアプリのコンテキストに参加するよう要求するという複合的な要因があります。バロニー。政府のセキュリティクリアランスインタビューは、ほとんどの人が予想するように多くの情報を求めますが、FBが「要求する」ものに近づくことはありません。私はアカウントを持っていますが、その在庫はコア機能にのみ使用されています。
そうは言っても、私はフェデレーテッドIDの概念と実践（openidやopen auth全般など）が好きです。いくつかの理由から、主要なWebメールプロバイダーによってサポートされているプロバイダーを使用することは、ユーザーの観点から議論するのは難しいと思います。フェデレーテッドIDの明らかな利点の1つ（記憶するログイン情報のペアが少ない、または別のローカルログイン情報ストアアプリまたはアドインで管理するなど）。 2つ目は、自分の資格情報（ユーザー名/パスの強度、機密情報の管理）を保護する限り、個人情報（およびその結果、受信トレイ）を保護するというかなり良い仕事をメールプロバイダーに任せています。
他のFederated Idプロバイダーを検討するかもしれませんが、Federated Idの目的に応じて、説得力のあるものにする必要があります。
最後に、多数のプロバイダーを統合することは必ずしも容易ではありません。 stackexchangeチームは、少し前に課題についてコメントしました。私がモバイルデバイスを使用していなかった場合、私はあなたを検索します。