このプラグインでGitLabとMicrosoft (Azure) を接続できました。(ちなみに、Azure ADサービスでは、クライアントIDとして「Application Client ID」を使用してください。シークレットIDや値ではありません。)
Discourseを2つのOIDCプロバイダー、例えばGitLabとAzureの両方と接続するにはどうすればよいですか?
編集: OAuth2でGitLabログインを機能させることができましたので、私の質問はより「理論的」なものになりました。
このプラグインでGitLabとMicrosoft (Azure) を接続できました。(ちなみに、Azure ADサービスでは、クライアントIDとして「Application Client ID」を使用してください。シークレットIDや値ではありません。)
Discourseを2つのOIDCプロバイダー、例えばGitLabとAzureの両方と接続するにはどうすればよいですか?
編集: OAuth2でGitLabログインを機能させることができましたので、私の質問はより「理論的」なものになりました。
プラグインをフォークして名前を変更し、2回設定できるようにする必要があると思います。おそらく、それをフォークして、どちらかのサービス用にハードコードすることになるでしょう。
Open ID Connect プラグインがコアにマージされ、その Git リポジトリがアーカイブされたため、フォークはもはや適切ではないと理解しています。
しかし、テナントごとに 2 つのアプリケーション(テナント 1 つあたり 1 つのアプリケーション)を登録したいと考えています。Open ID Connect プラグインの下で 1 つのテナントのアプリ登録が正常に動作しているため、2 つ目のアプリ登録 ID、シークレット、ディスカバリー URL を以下の設定に入力することは可能でしょうか?
このトピックのタイトルに対する解決策は、前の投稿にあると思います。2 つの OIDC を使う必要はなく、1 つの OIDC と 1 つの Microsoft_auth を使うだけで十分です。
microsoft_auth_email_verified は、Microsoft Auth の動作を既に設定済みの OIDC フローそのもののように変化させるものではありません。私の理解では、これは Microsoft が提供するメールをデフォルトで「確認済み/信頼済み」として Discourse が扱うようにするだけの機能です。これは、それらのメールが実際に確認されている場合、アカウントの連携や重複アカウントの回避に役立ちます:
ボタンテキストについては、OIDC は確かに js.login.oidc テキストネームスペースに属しています:
一方、Microsoft Auth は oidc ではなく microsoft_office365 翻訳ネームスペースを使用しているようです。例えば、以下のバグ報告では en.login.microsoft_office365.name が言及されています:
したがって、Microsoft Auth に関連するテキストキーのネームスペースは oidc ではなく microsoft_office365 だと考えられます。