ここでお話しされているのは、サーバー間の通信を必要としない OpenID Connect の “Implicit Flow” だと思われます。そのため、共有シークレットは不要です。代わりに、すべての情報は HTTP リダイレクト経由で送信され、ID トークンは Discovery Document の公開鍵を使用して暗号的に検証されます。
それは問題なく、有効な機能リクエストだと思います。しかし、これは共有シークレットを使用したサーバー間の通信を利用する、現在のプラグインのフローとは大きく異なるシステムです。そのため、ID トークンの暗号検証は不要です。これは、ある点ではよりシンプルですが、他の点ではより複雑です。
重要：プラグインのデフォルト実装を単純に変更することはできません。認可コードフローを使用しているサイトは、それを使い続ける必要があります。私の記憶が正しければ、多くの ID プロバイダーはインプリシットフローをサポートしていません。
そのため、ここには 2 つの進むべき道があると思います。
-
OIDC プラグインで「インプリシットフロー」のサポートを追加しますが、これはオプトイン機能とします。OpenID Connect gem を Discourse コアの依存関係として導入するプルリクエストは受け入れられない可能性が高いので、現在の戦略内で実装する必要があります。
discourse-lti (学習ツール連携) プラグインは、LTI プロトコルが OIDC インプリシットフローに基づいているため、参考になるかもしれません。ID トークンのデコードロジックは こちら にあります。
または
- インプリシットフローをまったく新しいプラグインとして構築します。この場合、実装に関して好きなように自由に実装できます（ただし、自分で保守する必要があります）。