新しいWebサイトに「Twitter / Facebookでサインイン」を使用することの長所と短所は何ですか？[閉まっている]

私と友人は小さなフォーラムサイトを立ち上げようとしています。ユーザーのログインに「Facebook / Twitterでサインイン」APIを使用することを検討しています（おそらく、たとえばLanyrdなど）。私はこれらのいずれも以前に使用したことも、ユーザーログインを使用してサイトを実行したこともありません。

これらのAPIの長所と短所は何ですか？具体的には：

1. 開発者としてそれらを使用することでどのような利点が得られますか？どんな欠点がありますか？

2. エンドユーザーは実際にそれらを好き/嫌いですか？

3. これらのAPIで技術的/物流上の問題を特に経験しましたか？

ここに私がこれまでに得た長所と短所を示します。

長所

• ユーザーにとってより便利です（2回のクリックで「登録」、1回でサインイン）
• おそらく独自のログインシステムを維持する必要はありません

 短所

• ログインプロセスを制御できない
• アカウントへの何らかのアクセスがあることを心配しているFacebook / Twitterユーザーを除外する
• Facebook / Twitterアカウントが侵害されると、サイトのユーザーアカウントが侵害されます。
• 独自の代替ログインシステムを維持しない場合：
  • ログインシステムのFacebook / Twitterへの依存
  • Facebook / Twitter以外のユーザーをサイトから除外する

私の言いたいことは、ユーザーは自分のFacebook / Twitterの資格情報を使用してサイトにログオンし、自分のサイトがそれらのアカウントのすべての情報に完全にアクセスできると考えていることです。

しないでください。

多くの人々、特に米国に拠点を置いていない人々は、Facebookアカウントを持たず、Facebookとそのユーザーのプライバシーの無知に関連して言われたことをすべて覚えているアカウントを作成しません。

多くの人が信じていることに反して、それらのソーシャルノイズ＆ジャンクサイトなしで幸せに暮らし、それらについて気にしない多くの人々がいます。

Facebookと呼ばれる大量のヒステリーに屈していないという理由だけで、顔に吐き出し、拒否するのはなぜですか？

考慮すべきその他の点：

1. 外部システムに依存させることにより、単一障害点を導入します。OpenIDをシャットダウンするか、代金を支払おうとすると、大混乱に陥ります。

2. 彼らはあなたのユーザーとそれをどうするかを知っている人に関するデータを収集します。少なくとも彼らはマーケティング目的でそれを使用し、最終的にはそれでお金を稼ぐでしょう、そして彼らはあなたにパイの一部を与えません。

3. それらをOpenIDプロバイダーとして採用することにより、準独占をさらにサポートし、さらに成長するのに役立ちます。コミュニティサービスを行い、その疫病に貢献しないでください。

もう1つの短所：FacebookやTwitter以外のユーザー（またはログイン情報を他のサイトと安全に共有できないと感じるユーザー）を除外します。または、外部アカウントを作成することで不便を引き起こします。個人的には、誰かが私のFacebook / Twitterログイン情報を取得すると、同じ情報を使用する他のサイトにアクセスできるという単一障害点の考え方が好きではありません。しかし、多分私はただの妄想です。

オプションとして使用されていることがわかりますが、FBまたはTwitterへのログインが必要な場合、多くの潜在的な訪問者を失うことになります。訪問者がFBアカウントを持っている場合でも、多くの人はプライバシーの目的でそれらを使用することを望みません。個人的に個人を特定する情報をランダムなサイトに与えたくはありません。

とにかく、サイトに関連するユーザー情報（設定など）を追跡したい場合があるため、とにかく何らかの形でユーザー追跡システムが必要になるでしょう。

私が頻繁に使用するサイトには独自のローカルログインシステム/ユーザーアカウントがありますが、ユーザーは自分のアカウントをFacebookアカウントにリンクするオプションがあります。したがって、これらの人々にとっては、選択すれば簡単にログインできるという利点があり、望まない場合にFacebookログインを使用することを強制されることはありません。それは非常にうまく機能すると思います。

ログインにOpenID、Facebook、Twitterを使用して遊んでみました。かつて私はそれをテストしていましたが、何らかの理由でFacebookを使用してログインできませんでした。Facebook開発者ページを見て、APIサーバーがダウンしていることに気付きました。Facebookがダウンタイムを抱えているためにユーザーがログインできない場合、これは大きな欠点です。TwitterもOpenIDと同じ問題を抱えているかもしれません。

それは本当にあなたのターゲット市場が何であるかによります。たとえば、一部のターゲット市場では、「非ユーザーを除外する」懸念はごくわずかです（ほとんどすべてのユーザーがそれらを持ち、喜んで共有しています）。他では、それは大きな問題です。

あなたは答えでここでそれを見ることができます：プログラマはセキュリティに非常に注意する傾向があり、アクセスを与えたくないので、すべての「NO！」回答:-p技術に詳しくない人はこれについてあまり注意を払っていません。

しかし、明らかな答えは、可能であればfb / twitterと独自のシステムの両方を実行することです。それから皆は幸せです。

私はFacebookアカウントを持っていますが、それを使用してログインしたいサイトに直面したとき、私はそうしません。別の方法がある場合は、それを使用します。そうでない場合、とにかくそのサイトに何があるのか​​本当に見たくありません。私はサイトに行って、そのサイトで他のFacebookの友人が何をしたかを見るのが嫌いです、それはあなたのプライバシーに不気味で邪魔です（特にFacebook経由でログインしたり、サイトにFacebookアカウントを伝えなかった場合）。

そのように純粋にそれを行うことの1つの欠点-複雑な外部依存関係なしにローカルでどのようにテストしますか？ランダムテストアカウントをどのように設定しますか？デモアカウント？人間以外のユーザーアカウントですか？通常、ほとんどのユーザーが資格情報を外部に保存することを希望している場合でも、これらの順列をカバーするローカル認証スキームが必要です。

最も重要なのは、インターネットに接続していない場合、アプリをハッキングすることさえできず、重要な作業をまったく行わないことです。また、認証または承認にバグがある場合、コードが正しいことを確認するために単純でローカルな何かを実行できない場合、facebook / twitter / other oauthの問題ではないことをどのように確認できますか？

外部ログインシステムを使用すると非常にうまく機能すると思います。openoverIDがstackoverflowとstackexchangeでどのように使用されたかを見てください。利点は素晴らしいです。すべてのログインシステムをコーディングする必要はありません。これは、最初のコードベースの大きな部分であり、単純に無視できます。また、間違える可能性もありません。他の誰かがどのような種類のパスワードで十分か、どのようにリセットするかなどを心配させることができます。そして、もし彼らがすでにどこかでopenidを持っているなら（ブログアカウントから、または彼らがstackoverflowにアクセスするためにセットアップしたもののいずれか）、彼らは別のユーザー名/パスワードの組み合わせを覚える必要はありません。

短所は、多くのユーザーが少し混乱することであり、外部サイトでopenidをまだ作成していない場合は作成しないことです。

Facebookのログインを使用すると、これらすべての利点に加えて、許可された場合にFacebookアカウントとやり取りする機会が得られます。

欠点は、あなたが独占的にFacebookのに依存している場合は、あなたが彼らに自分自身を抱き合わせていることである：Facebookはこれまで彼らのAPIを変更したり、あなたのサイトを禁止場合、またはそのような私のように、ユーザーがサイトにログインすることを拒否するデータのFacebookを共有する（している人そのデータを他の会社に漏らさないようになると、あまり慎重にならないことが知られています）。ページにFacebookの「いいね」または「ログイン」リンクがある場合でも、IIRC を使用すると、facebookでどのログインユーザーがサイトを表示するかをダブルクリックできます。

だから、私は言うだろう：

• 理想的には、openIDサイト、facebook、googleなどの複数の外部サイトでのログインを許可します。
• Facebookのログインフォームがある場合、最初のページに正しく表示せず、ユーザーが[Facebookでログイン]をクリックしたときにのみ表示します（そうするオプションがあることについて文句を言うつもりはありません:)） 。
• 最初に、設定が最も早いもの、アカウントとパスワード、またはopenIDなどを決定します。
• 外部ログインがある場合は、アカウントとパスワードも追加する価値があるかどうかを決定します。（ただし、少なくとも2、3の外部ログインが必要です）

私は少なくとも、ソーシャルメディアのヘッドライナー、特に選択的な情報の共有に対するリベラルな無視のためのFacebookには警戒しています。この不信感は、私が遭遇したアプリのほとんどと思われる大部分がすべての情報を要求し、次にアプリのコンテキストに参加するために知っているすべての人の情報を要求するという複雑な要因を持っています。バロニー。政府のセキュリティクリアランスインタビューでは、ほとんどの人が期待するように多くの情報が求められますが、FBの「要求」にさえ近づかないでください。私はアカウントを持っていますが、その在庫はコア機能にのみ使用されます。

そうは言っても、概念と実践においてはフェデレーションIDが好きです（一般的なopenidやopen authなど）。いくつかの理由から、主要なWebメールプロバイダーでサポートされているプロバイダーを使用することは、ユーザーの観点から議論するのは難しいと思います。フェデレーションIDの1つの明らかな利点（記憶する、または別のローカルログイン情報ストアアプリまたはアドインで管理するログイン情報のペアが少なくなるなど）。第二に、資格情報（ユーザー名/パスの強度、および露出を慎重に制御する）の一部を行う限り、メールプロバイダーが個人情報（および結果として、受信トレイ）を保護するかなり良い仕事をすることを信頼します。

他のFederated Idプロバイダーを検討することもできますが、Federated Idの目的に応じて、説得力のあるものにする必要があります。

最後に、多数のプロバイダーを統合することは必ずしも簡単ではありません。stackexchangeチームは、少し前に課題についてコメントしました。モバイルデバイスを使用していない場合は、検索を行います。

まあ、私はどうやら別のキャンプにいます。私にとって、Facebookの概念は時の試練に耐えるものです。おそらく、将来的にはFacebookにならないでしょう。しかし、プライバシーの陰謀論者の懸念を超えて（あなたのプライバシーを制御できます）、私の意見では、この種のサービスは「ユーティリティ」になるでしょう。誰かに電話をかけるために電話を拾うという点で、あなたはメールボックスを使い果たしてメールをつかむ...あなたは悪魔に「Facebook」で連絡を取ります。

代わりに、人々がお互いに「Facebook」を利用するようになったため、すでにメールトラフィックが大幅に減少しています。それは時間の問題だけですが、電子メールの使用は減少し続けます。

また、システムにログインするユーザーのタイプは、Facebookアカウントを持っているタイプである可能性が非常に高いことに注意してください。通常は（私の経験から）そうでない人は、とにかくあなたのサイトに「参加」するつもりはありません（または、その点で本当にどのサイトでも）。

実際、Facebookであるかどうかにかかわらず、誰もが承認した人と即座に通信できるシステムが、インターネットの「シングルサインオン」システムの最適な候補になるでしょう。「2クリック登録とno-click / 1クリックログイン」を小さなプロとして単純に却下することはできません、彼らは巨大です！

プライバシーを心配している人のために、Facebookのプロフィールに何を載せているのですか？なぜそこに置いているのですか？

私の投票は（それが価値があるもののために）それのために行くです！メンバーシップシステムをFacebookのみのシステムに完全に置き換えてください。私が持っている、そして私のユーザーはこれまでのところそれが好きです。