テストシステム（3.6.0.beta2-latest）でDiscourse_idを有効にしようとすると、次のメッセージが表示されます。
enable_discourse_id: この設定を有効にする前に、Discourse IDの認証情報（'discourse_id_client_id'および'discourse_id_client_secret'）を設定する必要があります。
ここでOIDC用のローカルOAuthサーバー（keycloak）を使用しています。両方の方法が干渉しているのでしょうか？
OIDCに干渉するとは思いませんが、あなたのインスタンスがインターネット上で利用できない場合、ID登録は機能しません。Discourse IDアイデンティティプロバイダーには、登録プロセスを開始するDiscourseインスタンスのための検証メカニズムが用意されています。
テストインスタンスは forum2.netzwissen.de でオンラインです
2つのインスタンスで同じメッセージが表示されていますが、どちらも異なるOAuth接続はありません。
これを別のトピックに移動しました…あなたのインスタンスの /logs でエラーは確認できますか？登録プロセス中に内部で何が機能していないかについての詳細が出力されるはずです。
技術的な側面からもう少し理解したいのですが。
私のインスタンスでは、外部IDプロバイダー（Keycloak 26）とOIDC認証を使用しています。Discourse IDは非常によく似ており、Discourse.orgがホストする別のIDPサーバーにすぎません。また、エラーメッセージ（クライアントIDとシークレットの欠落）も、従来のOAuthフローを彷彿とさせます。これは、Discourse IDが追加のIDP認証パスとしてアクティブ化されることを意味しますか？そうでないと、私のユースケースには役立ちません。???
これだけですが、比較的定期的に発生するため、トピックとは関係ありません。
メッセージ（2件報告あり）
Sidekiqが「rpg-foren-app」に対して過剰なメモリ（使用量：503.02M）を消費しているため、再起動します。
バックトレース
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:231:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/lib/demon/sidekiq.rb:59:in block in rss_memory_check’
/var/www/discourse/lib/demon/sidekiq.rb:53:in each' /var/www/discourse/lib/demon/sidekiq.rb:53:in rss_memory_check’
config/unicorn.conf.rb:132:in `block (2 levels) in reload
’
はい、その通りです。Discourse ID は別の IDP です。
@Tealk、sidekiq エラーは無関係です。インスタンスのコミットハッシュを共有していただけますか？
はい、こちらです：3.5.1 (c96aeda334)
わかりました。次に、パブリックアクセスワークフローの場合はIDPのクライアントID、または機密アクセスワークフローの場合はクライアントIDとクライアントシークレットが必要になります。別のオプションとして、Discourse IDをローカルIDPの外部IDブローカーとして追加することもできます。どちらのバリアントにも、もう少し情報が必要になります 
…
はい、各Discourseインスタンスは（内部的に）登録され、クライアントIDとシークレットが設定されます。
インスタンスを確認したところ、http/httpsエラーが見られます。IDが機能するには、サイトがhttps下にある必要があります。おそらくこれが問題です。
@Tealk、あなたのサイトもhttpsで正常に動作していることを確認してください。
改善できる点がわかりません。
Discourse IDは、安定版を使用しているフォーラムでも既に機能しますか？この機能は8月のリリース後にのみ追加されると思っていました。
ああ、確かに、あなたが stable チャンネルにいる場合、@Tealk さん、Discourse ID が利用可能になるまで次の安定版リリースを待つ必要があります。
また、DiscourseConnect は別の機能であることにも注意してください。
であれば、「新機能」ページで混乱が生じます。機能がどのバージョンから含まれているかを追加することは可能でしょうか？
それは良い点ですね。これで、安定版ではないインスタンス（かつ、Discourse IDを解除するコミットが latest に含まれているもの）にのみこのアイテムが含まれるように、「新着情報」フィードを更新しました。新着情報フィードを更新すると、安定版のインスタンスでこのアイテムが表示されなくなるはずです。
設定に設定がありますが、実装前に設定を利用できるようにする必要がありますか？
enable_discourse_id サイト設定は、あなたには存在しないはずです。（enable_discourse_connect と混同しないようにしてください。それは別のものです。）
あなたのインスタンスを見ると、http/httpsエラーがあります。IDが機能するには、サイトはhttps下にある必要があります。これが問題の原因でしょう。
…興味深いですが、なぜそうなるのか理解できません。概念的なギャップがあるのかもしれません。DiscourseコンテナはSSLアクセラレータの後方に配置されており、https経由でのみアクセス可能です。しかし、それは「外部」から「内部」への標準接続に対するものです。OAuthユースケースでは、Discourseコンテナは「内部」から外部にあるIDPへの接続を開始します。この接続を設定して「https」を強制するオプションは見当たりません。
自身のIDPとのOAuth設定に使用される従来のOIDC設定と比較すると、「OpenID Connect discovery document」設定があります。
https://....realms/[realm-name]/.well-known/openid-configuration
https接続の欠如による問題を回避するために、Discourse IDにも同様のものが必要だと思います。追伸：私のテストインスタンスは3.6.0.beta2-latest、Commits · discourse/discourse · GitHub
