公式 SSO スレッドに従ったのですが、ユニバーサルログインページが表示されないようです。
OAuth を有効にしただけでは正常に動作しました。「Auth0 でログイン」ボタンを使って問題なくログインできました。しかし、SSO を有効にすると Auth0 ページにリダイレクトされるものの、「invalid_request : Invalid parameter: client_id must be a string」というエラーページが表示されます。まず、「sso_url」に間違った値を入力しているのではないかと考えました。正直なところ、そこには何を入力すべきか全くわからず、「https://.auth0.com/authorize」と入力しました。
このような問題に遭遇した方はいらっしゃいますか？あるいは、何かアイデアはありますか？
sso url は、Discourse の SSO 要求を処理するために SSO プロバイダーサイトで設定した URL に設定する必要があります。
Discourse の SSO 実装は OAuth を使用しません。これが混乱の原因となっている可能性があります。
あなたの SSO プロバイダーサイトはどのような言語やフレームワークを使用していますか？すでにそのための SSO 実装が存在する可能性があります。
なるほどですね。Auth0 と Discourse の SSO は完全に別々のシステムです。両方を同時にサイト上で有効化することはできません。必要なのは、Auth0 がサイト上で正しく設定されていることを確認することだけのようです。
Discourse のセットアップが初めての方にとって、SSO 機能の誤解についてご共感いたします。これに関するトピックは存在しますが、特に一部の SSO 設定が Discourse を SSO プロバイダーとして使用するもの（Auth0 を使用したい場合と似たような仕組み）であるため、その違いが十分に明確に伝えられていないように思います。
SSO 機能で外部のアイデンティティプロバイダーを使用するには、discourse-sso-oidc-bridge のような仲介サービスが必要です。本日、Auth0 の代わりに Keycloak でこれを動作させることができました。Auth0 と Keycloak は概ね同様です。
Google、Facebook、GitHub などのソーシャルログインのように、単に Auth0 を使用したいだけであれば、おそらく discourse-openid-connect プラグイン を使用する必要があります。これをインストールし、提供される設定を使用してください。私は、個別の SSO 機能が登場する前に、Keycloak でこれを試しました。この方法では仲介サービスは不要で、ご希望の機能を提供してくれる可能性があります（ただし、ユーザーが再度ログインした際に Discourse の詳細情報が更新・同期されることを必要としない場合に限ります。Discourse がアカウント詳細を同期するのは、ユーザーがログインした時だけです）。
ユーザーにはアカウント作成が促されますが、すべてのフォームフィールドは認証プロバイダーから自動入力されます。将来的なプラグインのアップデートでは、このステップをスキップし、既存の SSO 機能のようにアカウントを直接作成すること（ただし、それが唯一のログインオプションである場合に限る）が予定されています。