上記の投稿 #2 の質問への回答として、私たちのユースケースと、必要なログインソースについてお伝えします。
私たちは EU の研究イニシアチブのための公開コミュニティフォーラムを運営しており、EU 内のマネージド Discourse ホスティング上で運用しています。
同時に 2 つの OIDC プロバイダーを有効にする必要があります。
- EU Login：欧州委員会の ID プロバイダーです。委員会の職員、政策関係者、EU 資金プロジェクトの参加者に利用されています。標準的な OIDC であり、ディスカバリードキュメントは
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configurationにあります。 - EGI Check-in：学術機関のアカウントと ORCID を前面に置く、連合型学術 ID プロキシです。欧州の研究インフラ全体で利用されています。こちらも標準的な OIDC です。
どちらのプロバイダーも、もう一方のユーザーをカバーしていません。政策担当者は EU Login でサインインしますが、学術機関の研究 ID は持っていません。研究者は大学アカウントまたはプロキシ経由の ORCID でサインインしますが、EU Login は持っていません。私たちのコミュニティはこれらの両方のグループで構成されているため、プロバイダーを 1 つに限定すると、フォーラムの対象となる人の半分を排除することになります。
両方のプロバイダーは通常の OIDC をサポートしており、それぞれ単独では動作します。問題なのは、discourse-openid-connect が単一の、番号なしの設定ネームスペース openid_connect_client_id を公開している点です。openid_connect_1_client_id や openid_connect_2_client_id のような形式ではありません。サイトごとに設定できる OIDC プロバイダーは 1 つだけです。
複数プロバイダーのサポートを希望します。最も自然な形は、プロバイダーごとの設定ネームスペースであり、番号付きの設定項目または管理者が管理するリストのいずれかです。これにより、各プロバイダーに独自のディスカバリードキュメント、クライアント認証情報、スコープ、ボタンタイトルを割り当てられます。
2021 年の Multiple openid-connect authentication providers という以前の事例があり、そこで必要とされていたのは複数の Keycloak レアルムの対応でした。それは別の形をした同じ制約です。
必要であれば、追加情報やテスト用の実装を提供できます。