Discourseの他のサイトアカウントを許可すると、重大なデメリットや問題がありますか?

Topicbox を非常にオープンな自己ホスティング型の Discourse へ移行する予定ですが、スパムやハッカーなどの問題も避けたいと考えています。Google、GitHub、およびその他のいくつかのソースによる認証を許可する予定です。

Discourse ID による認証を有効化することのリスクについては、過去に異なる意見が見られます。そこで、Discourse ID を使用したログインを許可することに関する現在の見解はどのようなものですか? 利点は潜在的な欠点やリスクを上回るのでしょうか、それとも Google の検索結果が示唆するように悪いのでしょうか? Discourse ID のリスクは、上記のソースによるログインを許可する場合と比べて、より重大でしょうか?

なぜ段階的に進めないのでしょうか?

まず、明らかに優先度の高いソーシャルログインから始めて、後で Discourse ID を追加するのはどうですか?

記載されているリスクのほとんどは、人々が「幻覚(ハルシネーション)」と呼ぶようなものです。

評判の不一致: 他のフォーラムで獲得した信頼レベル(TL0–TL4)が、あなたのコミュニティの基準と一致しない可能性があり、外部ユーザーにローカルでは獲得していない投稿権限やモデレーション権限を付与してしまう可能性があります。

Discourse ID はそのようなことはありません。

データ依存性: アイデンティティ検証のために外部サーバーやネットワークに依存します。リモートログインプロバイダーでダウンタイムが発生したり、API ルールが変更されたりすると、ユーザーがアクセスできなくなる可能性があります。

これはすべてのソーシャルログインに当てはまります。

連鎖的な脆弱性: サイトのセキュリティ態勢は、参加しているサイトの中で最も弱いもの、または中央のアイデンティティプロバイダーに依存することになります。外部のパートナーサイトが侵害されると、悪意のあるアクターがそのアカウントを利用し、あなたのインスタンスにアクセスする可能性があります。

Discourse ID は Discourse 上に構築されており、これはあなたのコミュニティが実行しているのと同じソフトウェアです。

アカウント乗っ取りの伝播: ユーザーが弱パスワードを使用していたり、リモートの参加サイトにおいて認証情報の漏洩に遭ったりした場合、その侵害された状態はあなたのフォーラムの認証フローに直接影響を及ぼす可能性があります。

これは理にかなっていません。

手間をかけずに多くのソーシャルログインを実現したい場合は、Discourse ID を使用してください。ユーザーがサイトにログインするために使用できる方法を厳密に制御したい場合は、使用しないでください。

海岸沿いを歩行する際のデメリット

表現の仕方が問題です :sweat_smile: