DiscourseSSO から DiscourseConnect へのアップデート以降、SSO 統合が機能しなくなりました。
私たちはやや特殊な構成を採用しています。単一のアプリケーションからではなく、複数のアプリケーションから SSO を開始できる環境です。当社のソフトウェアはオンプレミスまたはクラウド上のマルチテナント環境にインストール可能です。各テナントインスタンスには、Discourse コミュニティへの SSO リンクが含まれています。つまり、tenant1.ourcompany.com や software.tenant2.com、something.else.com など、ほぼ 1,000 の異なる場所から SSO を開始できます。
すべてのテナントにまたがる単一の中央アイデンティティプロバイダー（IDP）は存在しません。各テナントは独自の IDP ソリューション（Google、O365、AD、Okta など）を使用できます。サーバーサイドでは、アカウント乗っ取りに対する保護プロセスと緩和策を講じています。
残念ながら、このアプローチは最新の Discourse アップデートで機能しなくなりました（このコミット が原因と思われます）。技術的な観点から、以前は正常に動作していたフローは以下の通りでした。
- バックエンドが API を介して Discourse から nonce と SSO 詳細を取得
- Discourse が SSO ペイロードを含む 301 リダイレクトを、単一の特定のアドレスへ送信
- サーバー側では 301 リダイレクトを無視するように設定（nonce エラーを回避するため）。代わりに
Locationヘッダーを解析し、base64 値をデコードして nonce を取得、SSO ペイロードを生成し、SSO シークレットで署名後、ユーザーを SSO ログイン URL へ誘導
どうやら nonce の仕様変更により、CSRF 攻撃対策としてブラウザセッションに紐付けるように変更されたようです。そのため、上記のフローを試みると、Discourse へ戻される際にクライアントブラウザに nonce 用の _forum_session クッキーが存在せず、「nonce が期限切れ」というエラーが発生します。
この CSRF 保護をオプション化することは可能でしょうか？具体的には、enable_secure_nonce という新しい設定項目を false に設定できるようにすることはできませんか？
現状では、お客様の大多数がフォーラムへのアクセスを失っており、全員にパスワード設定を余儀なくされる事態に陥っています。また、アプリ内でのフォーラム通知の追跡機能も失われるため、エンゲージメントの低下が懸念されます。