@pfaffman さん、ご親切にありがとうございます。残念ながら予算がありません。
投稿した後、提案された記事の中に 2019 年の Disable DiscourseConnect という投稿を見つけました。これは明確なプロセスで役立ちますが、それが現在どのように機能しているかについて、まだ基本的な理解が不足しています。
ログインがリダイレクトされていないと確信しています。ログインページは、多くの Discourse 固有のアセット、データエクスポート、スクリプトなど、そして実行しているフォーラムの特定のコミットへのコンソールリンクを備えた、まさにプレーンな Discourse ログインフローのように見えます。
Discourse v3.5.0.beta3-dev — Commits · discourse/discourse · GitHub — Ember v5.12.0
これにより、Discourse が認証の独自の信頼できる情報源として機能していることはほぼ確実です。
私がまだ完全に理解できていないのは、DiscourseConnect の設定が external site からメール、ユーザー名などをオーバーライドするように設定されているのに、なぜか /session/sso_provider エンドポイントも有効になっているのかということです。これは、Discourse がサインオンの責任を放棄すると同時に信頼できる情報源としても機能しているようなものではないでしょうか？それとも、DiscourseConnect の SSO の仕組みについて、核となる理解やドキュメントを見落としていますか？
学習にご協力いただいている皆様、ありがとうございます。