Я не знаю достаточно о вашем стеке или случае использования, но, думаю, я уже решал похожую проблему раньше, и некоторые идеи могут быть вам полезны.
У меня есть приложение на Next.js, где клиентская часть должна иметь валидный JWT для вызова моего бэкенд-API, если существует сессия в Discourse.
Для этого я использую Discourse как провайдера идентификации через DiscourseConnect.
В моём случае я делаю это одним клиентским вызовом fetch с { credentials: "include" }, что работает только потому, что у меня всё настроено в рамках одного домена, а вызов fetch прозрачно следует за перенаправлениями.
Мой клиент запрашивает кастомный эндпоинт /auth/token, который проверяет наличие _t (просто чтобы избежать бессмысленного перенаправления) и возвращает редирект на защищённый URL /session/sso_provider, построенный согласно документации в связанной теме, с параметрами nonce/sso/sig и return_sso_url, указывающим на кастомный /auth/callback. Этот коллбэк извлекает данные, отправленные Discourse, формирует и возвращает JWT-токен, который клиент может использовать с этого момента.
Думаю, ваш случай использования можно решить аналогичным образом.