スタックやユースケースについて十分な知識はありませんが、以前類似の問題を解決したことがあり、いくつかのアイデアがお役に立つかもしれません。
クライアントサイドで有効なJWTを取得し、Discourseセッションが存在する場合にバックエンドAPIを呼び出す必要があるNext.jsアプリがあります。
このために、DiscourseをIDプロバイダーとしてDiscourseConnect経由で使用しています。
私の場合は、クライアントサイドの単一のfetch呼び出しで{ credentials: "include" }を使用してこれを行っています。これは、すべてを単一のドメインで設定し、fetch呼び出しがリダイレクトを透過的に追跡するためのみ機能します。
私のクライアントはカスタム/auth/tokenをフェッチします。これは、_tの存在を確認し（それ以外の場合は無意味なリダイレクトを回避するため）、リンクされたトピックのドキュメントに従って構築された保護された/session/sso_provider URLへのリダイレクトを返します。これには、nonce/sso/sig、およびDiscourseから送信されたデータを抽出し、クライアントがそれ以降使用できるJWTトークンを構築して返すカスタム/auth/callbackを指すreturn_sso_urlが含まれます。
あなたのユースケースも同様の方法で解決できると信じています。