Ich kenne Ihren Stack oder Anwendungsfall nicht gut genug, aber ich glaube, ich habe ein ähnliches Problem schon einmal gelöst, und einige Ideen könnten für Sie nützlich sein.
Ich habe eine Next.js-App, bei der die Client-Seite einen gültigen JWT benötigt, um Aufrufe an meine Backend-API zu tätigen, wenn eine Discourse-Sitzung vorhanden ist.
Dafür nutze ich Discourse als meinen Identitätsanbieter über DiscourseConnect.
In meinem Fall mache ich das mit einem einzigen clientseitigen fetch-Aufruf mit { credentials: "include" }, was nur funktioniert, weil ich alles mit einer einzigen Domain eingerichtet habe und der fetch-Aufruf transparent Weiterleitungen folgt.
Mein Client ruft einen benutzerdefinierten /auth/token ab, der auf die Existenz von _t prüft (nur um sonst eine sinnlose Weiterleitung zu vermeiden) und eine Weiterleitung zu einer gesicherten /session/sso_provider-URL zurückgibt, die gemäß der Dokumentation im verlinkten Thema mit nonce/sso/sig und einer return_sso_url erstellt wird, die auf einen benutzerdefinierten /auth/callback verweist. Dieser extrahiert die von Discourse gesendeten Daten, erstellt und gibt einen JWT-Token zurück, den mein Client von diesem Moment an verwenden kann.
Ich glaube, Ihr Anwendungsfall kann auf ähnliche Weise gelöst werden.