見落としている点がないか確認しています。download_avatar_url は、userinfo/picture 属性に基づいて呼び出され、その際アクセストークンが含まれないため失敗することは承知しています（Entra の場合、これは graph/me エンドポイントです）。インポータに認証ロジックを追加することは、条件分岐が多くなり、壊れやすくなるように思えます。
匿名で動作するアバターエンドポイントは持っています（外部 URL とユーザー名ベースの置換でテスト済み）。
通常であれば、Entra のオプションクレームでこのようなことを処理し、アプリケーション側でそれらのクレームを正しいフィールドにマッピングします。それは正常に行え、詳細な OIDC ログでクレームを含む適切にフォーマットされた JWT を確認できます。しかし、デフォルトのフローでは、アクセストークンを使用して userinfo を取得しますが、これは追加・変更できず、残りのクレームは破棄されます。
userinfo_endpoint が未定義の場合、JWT からクレームが使用されることに気づきました。問題は、これが discovery doc のコンテンツに基づいてトリガーされることで、.wellknown の一部であるため、調整できないことです。Ruby をハッキングして常に JWT を使用するようにするのは、応急処置です。ディスカバリドキュメントの「フォーク」を作成して、デプロイ時に公開から提供することも検討しましたが、これも非常に応急処置的です。
ディスカバリドキュメントをいじるのではなく、変数を設定（またはキュレート）するメカニズムを見落としているだけでしょうか？コードをパッチせずに、ディスカバリを使用するのではなく、それらを複製することに抵抗はありません。